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

L'HMI SCADA la disegni per l'operatore di linea, non per te: WPF o Blazor?

La scelta comincia proprio da lui.

Che poi non è un utente qualunque.

Lavora in un ambiente rumoroso, a volte con i guanti da lavoro, guarda uno schermo montato a due metri di distanza e ha pochi secondi per capire cosa sta succedendo.

Una valvola che si chiude quando non deve, un allarme di temperatura fuori soglia, un motore che va al massimo: ogni segnale ha un significato preciso e ogni ritardo ha un prezzo.

La risposta breve alla domanda è questa: WPF per il pannello dell’operatore di linea, Blazor per la dashboard di supervisione.

Regge nella grande maggioranza dei progetti SCADA, e nei progetti fatti bene convivono tutti e due nella stessa soluzione .NET.

Il resto serve a capire quando quella risposta non regge, perché è lì che si perdono i soldi.

Costruire un'interfaccia per un operatore di linea non assomiglia a niente altro nello sviluppo software.

Non è una questione di palette di colori o di animazioni curate.

Un pulsante troppo piccolo per un dito guantato, un allarme critico che visivamente si confonde con un avviso, un grafico che arriva mezzo secondo dopo.

Non sono difetti di esperienza utente, sono rischi operativi con conseguenze misurabili in pezzi, fermate e in qualche settore in incidenti.

Poi c'è l'altro utente, quello che non entra quasi mai in reparto.

Il responsabile di produzione vuole i suoi indicatori dall'ufficio, dal tablet in sala riunioni, dal telefono la domenica sera quando la linea si ferma.

Ha bisogno di un'interfaccia diversa, più analitica, che si apra da un browser senza installare niente su nessuna postazione.

Due persone, due necessità diverse, una sola squadra di sviluppo.

Ed è qui che la scelta del framework smette di essere una preferenza tecnica: un pannello operatore si installa, si configura e poi resta lì per anni, spesso senza aggiornamenti, finché la macchina non viene sostituita.

Sbagliarla significa convivere a lungo con operatori che aggirano l'interfaccia, ingegneri di processo che chiedono modifiche impossibili e costi di manutenzione che nessuno aveva messo in preventivo.

Qui dentro trovi il confronto tra WPF e Blazor su casi d'uso concreti, il pattern MVVM applicato a uno scenario SCADA vero, le librerie grafiche che reggono in produzione e il profilo professionale che il mercato italiano sta cercando e non trova.

Si comincia dal punto che quasi tutti saltano: cos'ha di diverso questa categoria di interfacce rispetto a qualsiasi altra applicazione tu abbia scritto finora.

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

Turno di notte, reparto imbottigliamento.

L'operatore ha appena preso in consegna la linea, ha i guanti addosso, e lo schermo davanti a lui mostra ottanta numeri contemporaneamente.

Nei prossimi otto minuti ne guarderà due.

Un'HMI SCADA si distingue da qualsiasi altra interfaccia per cinque requisiti che nessuna applicazione gestionale ha:

• Aggiornamento ad alta frequenza.
• Grafica simbolica di impianto.
• Allarmi gerarchizzati per priorità.
• Conferma esplicita dei comandi.
• Registrazione immutabile di ogni azione.

HMI sta per Human-Machine Interface, ed è il cruscotto attraverso cui una persona vede e comanda un impianto che lo SCADA, il sistema di supervisione e acquisizione dati, tiene sotto controllo per intero.

Il modo più rapido per capire cosa significhino davvero quei cinque requisiti è restare accanto a quell'operatore per un turno.

La prima cosa che guarda è il sinottico, cioè lo schema dell'impianto disegnato come l'impianto è fatto per davvero: serbatoi, pompe, valvole, tubazioni, ognuno al suo posto.

Non è un'illustrazione: ogni elemento cambia stato mentre lui guarda, la valvola si apre, il serbatoio si riempie, il motore cambia colore quando entra in allarme.

Questa grafica non esiste come componente pronto in nessun framework adatto a diversi utilizzi: le librerie commerciali arrivano fino allo strumento, il manometro o l'indicatore a led, non fino al tuo impianto.

È il primo scoglio.

Poi c'è la velocità.

Un impianto genera decine, centinaia, in certi casi migliaia di misure al secondo tra temperature, pressioni, portate, velocità e stati digitali.

L'interfaccia deve assorbirle tutte e non fermarsi mai, e nessuno dei due framework .NET che confronteremo tra poco regge questo ritmo allo stesso modo.

Un blocco di due secondi, quello che in un gestionale è un fastidio, qui è la finestra in cui un allarme critico compare e sparisce senza che nessuno lo veda.

Alle tre e dieci scatta l'allarme.

Ne scattano quattro insieme, per la precisione, perché in un impianto gli allarmi arrivano a grappoli: uno è critico, tre sono conseguenze.

Un sistema SCADA professionale gestisce centinaia di condizioni classificate per severità, con logiche di riconoscimento, silenziamento temporaneo ed escalation, e il compito dell'interfaccia è portare l'occhio dell'operatore sull'unico allarme che conta, non mostrarglieli tutti in ordine di arrivo.

Lui capisce, e clicca su "Apri valvola V-101".

L'interfaccia non esegue.

Chiede conferma: "Stai per aprire la valvola V-101 sul circuito di raffreddamento. Confermi?".

Quella finestra non è solo una precauzione: può rientrare nelle misure previste per ridurre il rischio di comandi involontari, secondo principi di sicurezza funzionale definiti da norme come la IEC 62061 e la ISO 13849-1.

La mattina dopo, alle nove, qualcuno chiederà chi ha aperto quella valvola e perché.

Ed è il quinto requisito: ogni azione, ogni comando, ogni parametro modificato finisce in un registro immutabile con utente, postazione, orario, valore precedente e valore nuovo.

Nel farmaceutico e nell'alimentare non è una funzionalità in più, è un obbligo di legge.

L'utente finale di un'HMI SCADA non è uno sviluppatore: è 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.

Se questo non è chiaro dal primo giorno, il progetto non fallisce con un errore: fallisce in silenzio, perché entro tre mesi gli operatori trovano il modo di scavalcare l'interfaccia e tornare a lavorare come facevano prima.

E la scelta tra WPF e Blazor decide quanto sarà difficile evitarlo.

Hai appena letto i cinque requisiti che nessuna applicazione gestionale ha.

Fermati un secondo e conta quanti ne rispetta l'ultima interfaccia che hai consegnato.

Nel Corso programmazione PLC lavori uno a uno con un architetto che quelle interfacce le ha messe in reparto, sul tuo codice, non su slide.

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

In un'azienda alimentare del Nord ho visto un pannello WPF acceso ininterrottamente dal 2016, aggiornato due volte in nove anni, su un PC che nel frattempo è passato di mano tra quattro capiturno.

Nessuno lo chiama "software": lo chiamano "la macchina".

WPF resta la scelta giusta per il pannello operatore di linea, e il motivo non è l'abitudine: è che nel 2026 nessuna alternativa in ambito .NET ha superato la combinazione di rendering accelerato dalla scheda grafica, binding con MVVM, grafica personalizzabile senza limiti, supporto touch nativo e integrazione con l'ecosistema Windows.

Microsoft lo ha introdotto nel 2006 e da allora è la tecnologia di riferimento per le interfacce industriali su Windows.

Ogni punto di forza si capisce meglio guardando il problema che risolve.

Parti dal momento in cui l'interfaccia dovrebbe cedere sotto carico e non lo fa: uno schema di impianto con duecento elementi animati e un trend con diecimila punti che si aggiornano insieme.

Con le vecchie applicazioni Windows Forms la CPU schizzerebbe al 100%, perché il disegno passa da GDI+.

WPF invece appoggia il rendering su DirectX: il lavoro pesante lo fa la scheda grafica, e la CPU resta libera per il compito che conta, cioè leggere i dati dal campo.

Il secondo problema arriva subito dopo, quando i tag da mostrare diventano quattrocento.

Aggiornare a mano quattrocento campi a schermo è il modo più veloce per scrivere un'applicazione che nessuno riuscirà più a modificare.

WPF è nato per MVVM: il ViewModel notifica una variazione con INotifyPropertyChanged e la View si aggiorna da sola, senza una riga di codice scritta da te per quel passaggio.

Su un'HMI industriale questo non è comodità, è la differenza tra un progetto manutenibile e quattromila righe di code-behind che che nessuno vuole più aprire.

Il terzo problema è la valvola.

Nessuno ha mai pubblicato un controllo "valvola a farfalla che ruota di novanta gradi e diventa rossa in allarme", perché ogni impianto ha i suoi simboli.

Con WPF quella valvola la disegni tu, esattamente come la vuole il cliente, animazione compresa e senza dipendere da una libreria esterna.

È la ragione per cui gli schemi P&ID, i disegni di processo e strumentazione, in ambito .NET si continuano a fare qui.

Il quarto problema sono i guanti.

I pannelli industriali moderni sono quasi tutti touch, e WPF supporta i gesti multitouch in modo nativo dal 2010, con le API dedicate.

Non serve aggiungere nulla per rendere un'HMI completamente utilizzabile anche con un dito dentro un guanto da lavoro.

Il quinto problema è quello che nessuno mette nei requisiti e tutti danno per scontato: l'operatore non deve avere una seconda password.

Su Windows l'HMI riconosce chi ha già fatto il login in azienda e non chiede altro.

Da lì legge la configurazione della macchina, parla con gli altri programmi sulla stessa postazione e, se serve, scende fino al sistema operativo.

È tutto documentato da vent'anni e funziona.

Sul fronte dei grafici non devi costruire niente da zero: per i trend fitti, per quelli curati esteticamente e per gli strumenti che imitano manometri e indicatori a led esistono già librerie collaudate.

Su quale scegliere e perché torniamo più avanti, con i numeri in mano.

La regola operativa è secca: scegli WPF quando il pannello è un PC Windows dedicato in reparto, quando gli aggiornamenti superano i cinque tag al secondo, quando la grafica di impianto è complessa e personalizzata, e quando l'interfaccia deve continuare a funzionare anche se la rete aziendale cade.

Tutto solido, tutto vero.

Fino al lunedì mattina in cui il direttore di stabilimento chiede di vedere l'andamento della linea dal suo telefono, mentre è in aeroporto.

Blazor per HMI SCADA: il web che entra in fabbrica

Quella domanda, in una fabbrica, mette in crisi un intero reparto IT.

Non perché sia difficile: perché il pannello che dovrebbe rispondere è avvitato a una parete e gira su un PC che non esce dalla rete di stabilimento.

Blazor non sostituisce WPF sul pannello di linea: apre un capitolo che prima richiedeva JavaScript e una squadra frontend separata, quello delle dashboard di supervisione consultabili da browser.

Per lo SCADA la variante corretta è quasi sempre Blazor Server, e il vincolo da conoscere prima di iniziare è la frequenza: fino due aggiornamenti al secondo funziona bene, sopra quella soglia no.

Le due varianti di Blazor si comportano in modo molto diverso in fabbrica.

Blazor Server tiene tutta la logica sul server ASP.NET Core e parla con il browser attraverso una connessione WebSocket gestita da SignalR: quando un dato cambia, il server calcola cosa è cambiato nell'interfaccia e manda al browser solo quel pezzo.

Blazor WebAssembly fa il contrario, scarica l'applicazione .NET dentro il browser e la esegue lì.

Per un dashboard industriale la seconda strada perde quasi sempre, e il motivo è banale: i dati stanno dove sta il backend, cioè accanto al server OPC UA, ai PLC, al database di storicizzazione.

Con Blazor Server il servizio che legge i dati e il codice che aggiorna l'interfaccia vivono nello stesso processo, e tra i due non c'è rete.

Con WebAssembly devi costruire un livello di API REST o gRPC in mezzo, esporlo, proteggerlo e mantenerlo, e in cambio ottieni più latenza e più superficie da difendere.

Il guadagno vero di Blazor è la sparizione della postazione.

Il responsabile apre il browser, si autentica, vede l'impianto.

Nessun client da installare, nessuna postazione da configurare, nessun aggiornamento da distribuire su cinquanta macchine.

In uno scenario di supervisione distribuita questo vantaggio su WPF non è marginale, è di categoria diversa.

Il limite sta nella strada che ogni singolo aggiornamento deve fare: nasce sul server, attraversa la rete, arriva al browser e solo lì diventa un numero che cambia sullo schermo.

In una rete aziendale locale questo giro costa tipicamente tra i 50 e i 200 millisecondi.

Per un responsabile che guarda gli indicatori ogni cinque secondi è invisibile.

Per un operatore che segue un processo con variazioni a 10 Hz è inutilizzabile, e nessuna ottimizzazione ti salverà, perché il ritardo è nel modello, non nel codice.

C'è poi un vantaggio che si vede solo nel bilancio della squadra: chi conosce già ASP.NET Core è produttivo su Blazor Server in pochi giorni, e la logica di business scritta per la dashboard è la stessa che serve alle API.

Non impari un framework nuovo, usi quello che hai già.

Due strumenti, due contesti, e la tentazione classica di sceglierne uno per sempre e chiudere la discussione.

È esattamente la decisione che, davanti a un cliente, va smontata criterio per criterio, perché a ogni criterio il vincitore cambia.

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

Sala riunioni, venti minuti, un cliente che vuole una risposta sola e ha sei domande in canna.

Le fa sempre nello stesso ordine, e a ogni domanda la risposta giusta rimbalza tra i partecipanti da una parte all'altra del tavolo.

Non esiste un vincitore assoluto tra WPF e Blazor per le HMI industriali: esistono sei criteri e per ognuno un vincitore diverso, e la scelta corretta dipende da quale criterio pesa di più nel tuo impianto.

"Quanto spesso si aggiornano i dati?" è la prima.

WPF aggiorna decine di volte al secondo senza sudare, con il limite pratico dei 60 Hz del monitor.

Blazor Server si ferma a uno o due aggiornamenti al secondo per via della latenza SignalR.

Su un pannello di linea non c'è partita, vince WPF.

Poi però il cliente ti spiega che sul pannello di linea guardano in tre, e la dashboard lo guardano in trenta.

"E da fuori si vede?" è la seconda, e ribalta il tavolo.

WPF gira su Windows desktop e basta.

Blazor gira su qualsiasi browser, su qualsiasi sistema operativo, su qualsiasi dispositivo, compreso il telefono del direttore in aeroporto.

Per la supervisione da remoto, in ambito .NET, non ha alternative.

"Ci servono i nostri simboli di impianto" è la terza, e il tavolo torna indietro.

WPF disegna qualsiasi cosa in modo nativo.

Con Blazor si può fare, a un prezzo: o esci da .NET e ti porti dentro una libreria JavaScript, o compri un pacchetto di componenti.

Sugli schemi P&ID complessi WPF è ancora avanti di parecchio.

"Chi aggiorna i pannelli?" è la quarta, ed è la domanda che gli sviluppatori sottovalutano e i responsabili della manutenzione no.

Con Blazor Server aggiorni il server e tutti i client hanno la versione nuova al prossimo accesso.

Con WPF ogni postazione va aggiornata singolarmente, e in uno stabilimento con cinquanta postazioni questo è un progetto a sé, con il suo calendario e il suo rischio.

"E se cade la rete?" è la quinta, e in fabbrica non è mai un'ipotesi.

WPF continua a funzionare, perché i dati arrivano dal server SCADA locale sulla stessa rete di reparto.

Blazor Server senza connessione al server si ferma, e l'operatore resta davanti a una pagina che non risponde proprio nel momento peggiore.

"Quanto costa l'hardware?" è l'ultima, e la fa sempre chi firma.

Un pannello WPF vuole Windows, memoria adeguata e un processore serio.

Un client Blazor gira su un terminale di rete economico, su un tablet Android, su un iPad di seconda mano: basta un browser aggiornato.

Su venti postazioni di sola consultazione, la differenza si vede a bilancio.

Sei domande, sei risposte diverse, ed è utile vederle una sotto l'altra prima di tirare la riga:

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.

Detta così sembra un compromesso.

In realtà è la decisione che ti costa di più, perché due interfacce vogliono dire due volte la logica degli allarmi, due volte le regole di accesso, due volte l'audit.

A meno di impostare il progetto nel modo giusto fin dal primo giorno, e il modo giusto comincia da come organizzi il codice del pannello WPF.

La tabella qui sopra ti dice cosa scegliere.

Non ti dice come tenere insieme le due cose senza raddoppiare il lavoro, e quella è la parte che separa un fornitore che rincorre da un tecnico che decide.

Nel Corso programmazione PLC parte proprio da lì, sul progetto che hai aperto adesso.

Quello che costruisci nelle sessioni finisce in produzione, non in una cartella di esercizi.

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

Il file si chiama MainWindow.xaml.cs e ha quattromila righe.

Dentro ci sono la connessione al campo, la logica degli allarmi, i colori, la formattazione dei numeri e tre commenti che dicono "non toccare".

Chi lo ha scritto non lavora più qui.

Questa è la fine naturale di ogni HMI scritta senza una struttura.

Il pattern MVVM in un'HMI SCADA divide il progetto in quattro strati:

• Il livello di comunicazione con il campo,
• Il Model che descrive il dominio industriale,
• il ViewModel che espone proprietà collegabili all'interfaccia,
• La View in XAML che le mostra.

Il vantaggio non è formale: ti permette di cambiare il modo in cui leggi i dati senza toccare la grafica, e di rifare la grafica senza rimettere le mani sulla logica.

Alla base c'è il livello che parla con l'impianto.

Si connette al server OPC UA, sottoscrive i tag che servono e riceve le notifiche quando i valori cambiano, usando la libreria della OPC Foundation per .NET Standard disponibile su NuGet.

Questo livello non sa che esiste WPF, e deve restare così: è la condizione che ti permetterà, più avanti, di riusarlo tale e quale nella dashboard Blazor.

Sopra c'è il Model, che è il vocabolario del tuo impianto tradotto in classi.

Un Tag con nome, valore corrente, unità di misura, tempo di campionamento e qualità del dato.

Un Alarm con severità e stato di riconoscimento.

Una Machine con il suo stato operativo.

Anche il Model ignora completamente l'esistenza dell'interfaccia.

Poi c'è il ViewModel, che è il cuore dell'HMI e anche il punto in cui i progetti industriali si rompono.

Implementa INotifyPropertyChanged, espone le proprietà collegabili alla View e contiene la logica di presentazione.

Il problema è che i dati arrivano da un thread secondario, quello del livello OPC UA, mentre in WPF le notifiche di variazione devono partire dal thread dell'interfaccia.

Ignorare questo dettaglio produce eccezioni che compaiono in produzione tre settimane dopo il collaudo e mai durante il collaudo.

La soluzione ha un nome, Dispatcher.InvokeAsync, ed è il passaggio obbligato che porta il valore dal thread che lo ha ricevuto dal campo al thread che lo deve disegnare.

Ogni notifica che arriva dallo SCADA attraversa quel varco prima di toccare una proprietà collegata alla View, temperatura del reattore e ora dell'ultimo aggiornamento comprese.

Costa una riga in più per ogni aggiornamento e ti risparmia la categoria di errore peggiore che esista in un'HMI: quella che non si riproduce mai in ufficio e si presenta puntualmente con l'impianto in marcia.

Per gli allarmi attivi il ViewModel espone una ObservableCollection che la View filtra e ordina attraverso una CollectionView.

La regola che vale in tutti gli impianti che ho visto è una sola: i critici stanno in cima, sempre, indipendentemente dall'ordine di arrivo.

Un allarme critico scivolato in fondo alla lista perché ne sono arrivati altri quaranta è un difetto grave, anche se il software funziona esattamente come è stato scritto.

La View, cioè lo XAML, traduce le proprietà in cose che si vedono.

Il binding di WPF non lega solo i valori: lega i colori, la visibilità, le animazioni.

L'indicatore che diventa rosso quando la temperatura supera la soglia non è codice, è un binding con un Converter che trasforma un numero in un colore.

E siccome è una regola dichiarata invece che una procedura scritta, il giorno in cui la soglia cambia, cambi un parametro e non una funzione.

I comandi dell'operatore non vivono dentro il pulsante: sono oggetti a sé, che la View si limita a richiamare.

Il pulsante non sa cosa succede quando viene premuto, sa solo quale comando eseguire e se in questo momento è abilitato: è così che si costruiscono i livelli di accesso senza riempire il codice dell'interfaccia di controlli sui permessi.

Sopra tutto questo vale un divieto che non ammette eccezioni: il thread dell'interfaccia non si blocca mai.

Ogni operazione di ingresso e uscita, la lettura dal database, l'invio di un comando al PLC, la scrittura del registro di audit, va fatta in modo asincrono.

Duecento millisecondi di attesa sincrona sono un'HMI che smette di aggiornarsi, e un operatore che in quei duecento millisecondi non vede quello che sta succedendo.

La struttura regge.

Il vero collaudo però lo fa un componente solo, quello che sta al centro dello schermo e che tutti guardano per primo.

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

Il manutentore non guarda il valore della vibrazione.

Guarda la sua forma negli ultimi trenta minuti, perché è lì che si vede se un cuscinetto sta morendo.

Quel grafico è il componente più critico di tutta l'interfaccia, ed è anche quello che fa cadere più progetti.

Per i trend in tempo reale in WPF la scelta è ScottPlot quando la frequenza supera i 5 Hz o i punti superano i diecimila.

Sotto quelle soglie entra LiveCharts2, che rende meglio esteticamente.

Il criterio è quantitativo, non è questione di gusto.

La ragione per cui i grafici industriali si piantano ha un nome che nessuno associa alla grafica: il garbage collector.

Immagina un addetto alle pulizie che passa quando decide lui e, per fare il suo giro, spegne la luce per qualche decina di millisecondi.

Se ogni punto del grafico è un oggetto .NET separato, un trend che riceve 100 punti al secondo e conserva dieci minuti di storia ne ha 60.000 in memoria, tutti da raccogliere prima o poi.

Le pause si vedono, e si vedono proprio quando il grafico si muove di più.

La soluzione non è ottimizzare il disegno: è non creare gli oggetti.

Array circolari di tipi primitivi, cioè double allocati una volta sola e riusati per sempre, invece di liste di oggetti che nascono e muoiono a ogni campione.

ScottPlot nasce esattamente per questo.

È una libreria pensata per i grafici scientifici e industriali ad alta frequenza in WPF e WinForms: internamente lavora con array di double preallocati e disegna direttamente su bitmap.

Il risultato pratico è un grafico che si aggiorna a 60 Hz con centomila punti senza consumo di CPU misurabile, e che accetta aggiornamenti da thread secondari senza bloccare l'interfaccia.

L'errore comincia qui: decidi una volta sola quanta storia vuoi tenere e dimensioni la memoria su quella, 36.000 posizioni ti danno un'ora di dati campionati a 10 Hz, e sono due sequenze di numeri, una per i tempi e una per i valori, allocate all'avvio e mai più.

Poi ci giri dentro in modo circolare: l'indice avanza a ogni misura, quando arriva in fondo riparte da zero e il punto più vecchio viene sovrascritto dal più nuovo.

Niente si crea, niente si butta, l'addetto alle pulizie non ha nulla da raccogliere e il grafico si limita a ridisegnare quello che trova.

Due sequenze di numeri e un contatore: è tutta qui la differenza tra un trend che regge un turno intero e uno che comincia a singhiozzare dopo venti minuti.

LiveCharts2 gioca un altro campionato.

Ha un modello a oggetti più ricco, con serie, punti e assi dalle etichette formattate, e produce grafici visivamente più curati, con animazioni fluide e suggerimenti interattivi al passaggio del mouse.

Il prezzo è una macchina interna più complessa e prestazioni inferiori sui dataset grandi.

Per un dashboard direzionale in WPF, con aggiornamenti sotto i 5 Hz, è la scelta migliore.

Per il trend di un reattore, no.

Syncfusion e Telerik risolvono un problema diverso dai trend.

Offrono i manometri circolari, gli indicatori lineari, i display digitali e le macchine a stati animate, cioè i componenti che replicano l'aspetto degli strumenti fisici che l'operatore conosce da vent'anni.

Il vantaggio è tempo di apprendimento quasi zero per chi userà l'interfaccia, il costo è una licenza commerciale da mettere a preventivo prima, non dopo.

Messe in fila, le tre famiglie rispondono a tre esigenze diverse:

Restano due numeri da tenere a mente: sopra i 5 Hz o sopra i diecimila punti si va su ScottPlot, sotto si può scegliere in base all'estetica.

Quello stesso numero, però, non serve solo all'operatore in reparto: qualcuno lo aspetta anche fuori dal capannone, e per lui la strada è un'altra.

Dashboard SCADA con Blazor Server e SignalR: architettura e implementazione

Giovedì mattina, giro di stabilimento.

Il direttore cammina lungo la linea con un tablet in mano e guarda i semafori delle macchine mentre le supera.

Non è una scena da presentazione commerciale: è il caso d'uso che giustifica l'intera architettura di questa sezione.

La dashboard SCADA con Blazor Server ha tre livelli: un servizio in background legge i dati industriali, un Hub SignalR li distribuisce ai client connessi, i componenti Blazor si iscrivono e ridisegnano l'interfaccia.

Per una dashboard di supervisione, pubblicare gli aggiornamenti ogni due o cinque secondi è più che sufficiente.

Il servizio in background è un IHostedService che vive quanto vive l'applicazione ASP.NET Core.

Legge da OPC UA, da un database time-series o dalle API interne dello SCADA, e pubblica le variazioni sull'Hub.

Qui la tentazione da evitare è pubblicare tutto quello che arriva: il campo genera molto più di quanto un essere umano possa guardare, e una dashboard che aggiorna trenta volte al secondo un numero che nessuno legge consuma banda e batteria per niente.

L'Hub SignalR è il punto di distribuzione.

I client Blazor si collegano e ricevono messaggi tipizzati in C#, senza che tu debba scrivere una riga di JavaScript, e SignalR gestisce da solo la riconnessione quando la rete fa i capricci, con una logica di tentativi configurabile.

Sul componente Blazor il ciclo di vita va rispettato alla lettera, altrimenti il problema si presenta in una forma sgradevole: memoria che cresce piano per giorni.

In OnInitializedAsync il componente si iscrive all'Hub e chiede i dati iniziali.

Nel metodo di richiamo aggiorna le proprie proprietà e chiama StateHasChanged per far ridisegnare l'interfaccia.

E implementando IAsyncDisposable cancella la sottoscrizione quando il client se ne va.

Il terzo passo è quello che si dimentica, e si paga la settimana dopo.

La dashboard che ne esce è quello che il responsabile di produzione voleva dall'inizio: lo stato di tutte le macchine della linea a colpo d'occhio, verde in produzione, giallo in attesa, rosso in allarme, l'OEE complessivo aggiornato mentre si guarda, le ultime dieci segnalazioni di allarme e i numeri della giornata, pezzi prodotti e scarti.

Lo stesso indirizzo si apre dal laptop in ufficio, dal tablet in reparto e da casa durante un fermo notturno, senza la necessità di configurare nulla.

Poi c'è la parte che quasi tutti trascurano, ed è quella che decide la fiducia dell'utente: cosa succede quando la connessione cade.

In Blazor Server la sessione resta viva sul server per un tempo configurabile, tipicamente tre minuti, in attesa che il client torni.

Se rientra nel tempo, riceve lo stato aggiornato e nessuno si accorge di niente.

Se il tempo scade, la sessione muore e il client deve ricaricare la pagina.

In entrambi i casi l'interfaccia deve comunicarlo in modo esplicito, con un indicatore di stato della connessione sempre visibile.

Un numero fermo che sembra aggiornato è peggio di un errore dichiarato: il primo lo credi, il secondo lo verifichi.

A questo punto però quel dashboard è una pagina raggiungibile da un browser.

Il che porta la domanda successiva, quella che in fabbrica arriva sempre da chi ha il potere di fermare il progetto: da chi, esattamente, è raggiungibile?

Chi può fare cosa in un'HMI SCADA: livelli di accesso, ruoli e audit log

Pausa pranzo.

Il pannello resta acceso con la sessione dell'operatore aperta, in un corridoio dove passano manutentori, fornitori e il ragazzo dello stage.

Il software funziona perfettamente.

È l'organizzazione intorno che ha appena smesso di funzionare.

Un’HMI SCADA ben progettata assegna a ogni utente un livello, ossia solo le operazioni consentite dal suo ruolo e registra in un audit log protetto le azioni rilevanti.

In alcuni settori e per determinati impianti, controllo degli accessi e tracciamento delle operazioni non sono soltanto buone pratiche, ma requisiti di conformità.

È il caso della FDA 21 CFR Part 11 per i sistemi farmaceutici soggetti alla normativa statunitense, della famiglia IEC 62443 per la sicurezza dei sistemi di automazione industriale e delle norme NERC CIP per determinate infrastrutture elettriche nordamericane.

Il modo migliore per capire i quattro livelli è seguire un problema che sale.

La linea si blocca in una condizione anomala.

L'Operatore, che è il livello base, vede tutto e comanda quello che serve per produrre: avvia il ciclo, riconosce gli allarmi, chiude il turno, sceglie il prodotto.

Quello che non può fare è cambiare i parametri di processo, e in questo momento è esattamente ciò che servirebbe.

Chiama il Supervisore.

Il Supervisore ha le stesse possibilità dell'operatore più la facoltà di modificare i parametri operativi dentro intervalli predefiniti, come un setpoint di temperatura o la velocità di linea, di silenziare un allarme specifico lasciando scritta la motivazione, e di sbloccare le situazioni di stallo.

Nove volte su dieci la storia finisce qui.

La decima volta serve l'Ingegnere di processo, che è l'unico a poter mettere le mani sulle soglie di allarme, sulle ricette di produzione e sulla configurazione delle logiche di controllo.

Da questo livello in su ogni azione cambia il comportamento del sistema per tutti i turni successivi, e deve essere tracciata in modo che tra sei mesi si capisca ancora chi ha deciso cosa.

L'Amministratore non compare mai durante il turno.

Compare prima, quando crea gli account e assegna i ruoli, e dopo, quando qualcuno chiede di leggere i log completi.

È l'unico a poter creare utenti o cambiare permessi, e proprio per questo è il ruolo che va dato a meno persone possibile.

Visti uno accanto all'altro, i quattro livelli si distinguono meno per quello che possono fare e più per il confine che nessuno di loro può superare:

Sul come autenticare, in ambiente industriale la risposta cambia con il framework.

Su WPF si usa quasi sempre l'autenticazione Windows integrata: il PC è nel dominio, l'operatore si autentica al login del sistema, l'applicazione ottiene l'identità tramite WindowsIdentity e i ruoli si mappano sui gruppi di Active Directory, senza una schermata di accesso dedicata da mantenere.

Su Blazor Server si usa ASP.NET Core Identity, con autenticazione integrata quando si è dentro la rete aziendale e autenticazione a modulo quando si accede da fuori, proteggendo pagine e componenti con l'attributo Authorize e le policy di accesso.

Il registro di audit è il requisito che attraversa tutti e quattro i livelli, e va progettato prima di scrivere la prima schermata.

Ogni comando inviato alla macchina genera una riga con tempo preciso e fuso orario, nome utente, postazione, azione, oggetto interessato, valore precedente, valore nuovo ed esito.

Quel registro sta su un archivio separato, in sola aggiunta, e non deve essere modificabile dall'HMI nemmeno da chi ha i permessi massimi.

Se l'amministratore può correggere il log, il log non vale niente in un audit, e in farmaceutico questo si traduce in un rilievo formale.

Torniamo al pannello lasciato acceso in corridoio: la misura che lo risolve costa mezza giornata di lavoro ed è il timeout di sessione con nuova autenticazione dopo un periodo di inattività.

Semplice, noiosa, e sistematicamente rimandata.

Nel frattempo, però, hai due interfacce da proteggere con le stesse regole: un pannello WPF e una dashboard Blazor.

Se scrivi quelle regole due volte, prima o poi divergeranno, e a divergere sarà proprio la parte che un ispettore va a controllare.

Le regole scritte due volte divergono sempre, e divergono nel punto peggiore: quello che un ispettore apre per primo.

Non è un rischio teorico, nel farmaceutico e nell'alimentare è un rilievo formale con il suo verbale.

Nel Corso programmazione PLC il registro di audit lo progetti prima della prima schermata, come va fatto.

Costruisci ruoli, permessi e log immutabile una volta sola, e li fai valere sia sul pannello WPF sia sulla dashboard Blazor.

Integrare WPF e Blazor nello stesso progetto SCADA: architettura ibrida

Due repository, due team, due logiche di allarme.

Sul pannello un allarme critico resta attivo finché l'operatore non lo riconosce, sulla dashboard si spegne da solo quando il valore rientra.

Nessuno dei due è sbagliato: sono due decisioni prese in momenti diversi da persone diverse, ed è il modo più elegante di perdere la fiducia del cliente.

Sì, si possono avere entrambe le interfacce nello stesso progetto, ed è l'architettura raccomandata per i progetti SCADA professionali nel 2026: la logica di business vive in librerie .NET indipendenti da qualsiasi framework di interfaccia, e viene consumata sia dall'applicazione WPF sia dall'applicazione ASP.NET Core che ospita Blazor Server.

La separazione va fatta in un punto preciso.

Tutto quello che riguarda l'impianto, la lettura dei dati da OPC UA, la gestione degli allarmi, la scrittura del registro di audit e le regole operative dello stabilimento, non deve sapere se verrà mostrato in XAML o in HTML.

Se lo sa, hai già perso: quella conoscenza si infiltra ovunque e in sei mesi le due interfacce diventano due prodotti diversi.

In pratica la soluzione Visual Studio si compone di quattro progetti:

1. Modelli di dominio: una libreria con Tag, Alarm, Machine e AuditEntry.
2. Servizi: una libreria con OpcUaService, AlarmService, AuditLogService e HistoryService.
3. Pannello di reparto: un progetto WPF che consuma quei servizi.
4. Dashboard web: un progetto ASP.NET Core con Blazor Server che consuma gli stessi servizi.

Con questa struttura il codice di comunicazione con il campo si scrive una volta sola.

E soprattutto la regola dell'allarme critico che resta attivo finché non viene riconosciuto sta scritta in un punto solo, nel livello dei servizi; quindi, il pannello e la dashboard si comportano allo stesso modo perché eseguono letteralmente lo stesso codice.

Resta da decidere come le due interfacce restano allineate.

La strada semplice è condividere il database come unica fonte di riferimento: il pannello scrive l'azione dell'operatore, la dashboard la rilegge.

Funziona, è banale da spiegare a chiunque, e introduce un ritardo pari all'intervallo di lettura.

La strada più raffinata usa un canale interno, per esempio System.Threading.Channels o una coda leggera, in modo che ogni variazione di stato venga propagata subito a tutti i consumatori, pannello e dashboard compresi.

C'è poi un pattern che vale la pena conoscere: lo stesso ViewModel di dominio, quello che rappresenta lo stato di una macchina, usato da entrambe le parti.

In WPF implementa INotifyPropertyChanged e la View si aggiorna da sola.

In Blazor Server il componente osserva le stesse proprietà e chiama StateHasChanged quando cambiano.

Un solo modello mentale per due tecnologie, e un nuovo arrivato nel team ne impara uno invece di due.

Questa architettura non è più difficile da mantenere di una monolitica: è meno costosa, perché elimina la duplicazione e garantisce che le due interfacce raccontino la stessa storia.

Ha però un effetto collaterale che va guardato in faccia: hai appena messo una pagina web davanti a un impianto industriale, e quella pagina qualcuno la cercherà.

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

Nel 2021 a Oldsmar, in Florida, qualcuno è entrato nel sistema di controllo dell'acquedotto e ha provato a modificare il dosaggio della soda caustica nell'acqua potabile.

Nel 2015 un attacco alla rete elettrica ucraina ha lasciato al buio centinaia di migliaia di persone.

In entrambi i casi il punto di ingresso era un'interfaccia di controllo, cioè un oggetto simile a quello di cui stiamo parlando in questo articolo.

Le HMI industriali si difendono su quattro fronti:

• Segmentazione della rete,
• Autenticazione forte,
• Principio del privilegio minimo
• Un processo di aggiornamento che esista davvero.

Nessuno dei quattro è tecnologia esotica, e proprio per questo la loro assenza è difficile da spiegare dopo.

Il problema di fondo è generazionale.

Queste interfacce sono state progettate quando la sicurezza informatica in fabbrica non era un tema, perché i sistemi erano isolati fisicamente: nessuna connessione verso l'esterno, nessuna possibilità di raggiungerli.

Con Industria 4.0, il cloud e il monitoraggio remoto quell'isolamento è finito, ma le difese sono rimaste quelle di prima.

La prima misura è la segmentazione.

La rete OT, dove vivono PLC, server SCADA e pannelli, deve essere separata dalla rete IT aziendale, con una DMZ e un firewall in mezzo che lasci uscire i dati verso l'IT senza lasciare entrare nulla in senso opposto se non attraverso controlli espliciti.

È noiosa da progettare e trasforma un attacco riuscito in un attacco circoscritto.

La seconda è l'autenticazione seria.

Le HMI WPF usano l'autenticazione Windows con Active Directory, non utenti e password locali scritti in un file di configurazione.

Le dashboard Blazor esposti sulla rete aziendale usano HTTPS obbligatorio e autenticazione a più fattori.

Le connessioni OPC UA usano la modalità SignAndEncrypt con certificati X.509, che autentica client e server e cifra tutto quello che passa.

La terza è il privilegio minimo, e si applica al software non meno che alle persone.

Il servizio che legge i dati deve avere il permesso di lettura sui tag che gli servono e niente altro.

Il servizio che invia comandi deve poter scrivere solo sui nodi che l'HMI deve comandare.

Quando un attaccante prende il controllo di un processo, eredita esattamente i permessi che quel processo aveva: la domanda giusta non è "come impedisco che accada", è "quanto danno può fare se accade".

La quarta è la meno tecnica e la più disattesa.

Un pannello in fabbrica non riceve aggiornamenti perché vale la regola non scritta secondo cui non si tocca ciò che funziona.

Dopo qualche anno quella macchina accumula vulnerabilità note, con exploit pubblici e documentati, e resta collegata alla rete.

La soluzione non è aggiornare alla cieca: è avere un ambiente di test equivalente alla produzione, validare gli aggiornamenti prima, e avere una procedura di ripristino rapida.

Costa molto meno di un impianto fermo per un incidente informatico, e questa è una di quelle affermazioni che nessun direttore contesta finché non deve firmarne il budget.

Tutto questo lo deve saper fare una persona sola, o un piccolissimo gruppo di persone.

Il che porta alla domanda che a questo punto ti stai facendo: quante persone conosci che sappiano davvero fare tutto quello che c'è scritto qui sopra?

Il mercato delle HMI industriali in Italia: opportunità per gli sviluppatori .NET

Un system integrator dell'Emilia mi ha detto che per una posizione del genere ha tenuto l'annuncio aperto per sette mesi.

Riceveva candidature di sviluppatori bravissimi.

Nessuno di loro aveva mai visto un impianto in funzione, e questo, nel suo mestiere, non è un dettaglio del curriculum.

Il profilo che il mercato italiano cerca e non trova non è genericamente lo sviluppatore .NET nel manifatturiero: è chi disegna le interfacce di sala controllo, cioè chi sa mettere un pannello WPF davanti a un operatore con i guanti e una dashboard Blazor davanti a un direttore di stabilimento, sapendo perché sono due mestieri diversi.

È una specializzazione, non un settore.

Il contesto spiega la domanda.

l manifatturiero italiano è il secondo dell’Unione europea per valore aggiunto, dopo la Germania (dati Eurostat 2025): automotive, alimentare, farmaceutico, petrolchimico, meccanica di precisione e servizi di pubblica utilità.

Sono impianti da centinaia di milioni di euro il cui funzionamento quotidiano dipende da software di supervisione scritto e mantenuto da qualcuno, e quel qualcuno deve conoscere .NET e C#, i protocolli industriali come OPC UA, Modbus e Profinet, la costruzione di interfacce in WPF e in Blazor, e il contesto operativo in cui quelle interfacce verranno usate.

Le quattro cose insieme sono rare, e la rarità qui non è un modo di dire dei selezionatori.

La prima porta si apre quasi sempre dal lato dei system integrator specializzati in automazione, i partner certificati Siemens o Rockwell, che costruiscono soluzioni SCADA su misura per i loro clienti.

Si entra su progetto, si vedono molti impianti diversi in poco tempo e si impara alla velocità a cui si è costretti a imparare quando il cliente è in linea.

Molti di quei contratti si trasformano in rapporti lunghi, perché la manutenzione evolutiva di un impianto non finisce mai.

La seconda porta non compare negli annunci, ed è quella delle aziende manifatturiere con un ufficio tecnico interno.

Cercano chi mantenga ed evolva i loro sistemi SCADA proprietari, spesso senza pubblicare nulla all'esterno, per passaparola.

Chi entra da lì diventa nel giro di due anni il riferimento tecnico della produzione, una posizione con poca visibilità sul mercato e moltissima dentro l'azienda.

La terza porta è quella dei fornitori di software SCADA, da Inductive Automation con Ignition ad Aveva, Citect e realtà italiane come Progea, che cercano sviluppatori per estendere le loro piattaforme con moduli scritti in .NET o in Java.

Qui si lavora su prodotto invece che su commessa: meno impianti, più profondità, e il codice che scrivi finisce in stabilimenti che non vedrai mai.

Le tre porte portano allo stesso mestiere per strade molto diverse:

• System integrator specializzati in automazione: si entra su progetto, si vedono molti impianti diversi in poco tempo e la manutenzione evolutiva trasforma le commesse in rapporti lunghi.
• Aziende manifatturiere con ufficio tecnico interno: posizioni che non compaiono negli annunci, si arriva per passaparola e in due anni si diventa il riferimento tecnico della produzione.
• Fornitori di software SCADA: da Ignition ad Aveva, Citect e Progea, si estendono le piattaforme dall'interno e si lavora su prodotto invece che su commessa.

Le competenze HMI e SCADA pagano più della media del settore software italiano, e il premio più alto va a chi ha lavorato su impianti critici nel farmaceutico o nell'energia.

Quanto più alto, e a quale livello di esperienza, sta scritto con le cifre nell'articolo sulla modernizzazione dei sistemi SCADA legacy.

La differenza rispetto a uno sviluppatore .NET generico non sta nella difficoltà del codice: sta nel fatto che l'offerta è scarsa e il ruolo è critico.

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, e alla produzione non interessa se la causa è meccanica o è il software di supervisione.

Chi sa rimettere in marcia l'impianto, o meglio ancora evitare che si fermi, viene pagato in proporzione a quel numero.

Costruire questo profilo richiede però un percorso preciso, e conoscere C# e WPF è solo il punto di partenza.

Bisogna capire come lavora un PLC, cosa è un tag e come si legge via OPC UA, come si struttura un sistema di allarmi secondo le indicazioni della ISA-18.2, e come si progetta un'interfaccia che un operatore con vent'anni di esperienza su quella macchina trovi ovvia al primo sguardo.

L'ultima è la più difficile, e non si impara leggendo.

Il punto di partenza concreto costa zero e sta tutto sulla tua macchina: un piccolo simulatore di PLC con un client OPC UA in C#, un'HMI WPF con un trend in tempo reale e qualche allarme finto, una dashboard Blazor che mostra gli stessi dati nel browser.

Non serve hardware industriale, esistono simulatori OPC UA gratuiti con cui sviluppare e collaudare tutta la logica di comunicazione.

È il progetto che, in un colloquio, sposta la conversazione dalle domande di teoria alle domande vere.

Da lì in poi quello che manca è il pezzo che nessun video ti dà: qualcuno che guardi il tuo codice e ti dica dove si romperà in reparto, che è una cosa diversa dal dirti se compila.

In Sviluppatore Migliore seguo personalmente le persone, quindi i posti sono pochi e non prendo tutti: se dal confronto emerge che questa strada non ha senso per te, preferisco dirtelo prima che dopo.

Il mercato è lì, è concreto e non si sposta: le interfacce di sala controllo di questo paese qualcuno le deve disegnare, e in questo momento le aziende che le cercano sono molte di più delle persone in grado di consegnarle.

Puoi chiudere questa pagina e tornare a scrivere gestionali.

Funziona, si campa, e tra cinque anni farai esattamente le stesse cose con un framework diverso.

Oppure prendi la strada stretta, quella che quasi nessuno percorre perché richiede di uscire dall'ufficio e mettere piede in un reparto.

Le competenze HMI e SCADA pagano più della media del settore software italiano, e il premio più alto va a chi ha lavorato su impianti critici.

Il Corso programmazione PLC è il percorso più corto che conosco per arrivarci.

I posti sono pochi.

Non è un mestiere per tutti: è un mestiere per chi vuole che il proprio software conti qualcosa quando la linea si ferma alle tre di notte.