WPF for the Operator Panel, Blazor for the Manager Dashboard: The Definitive Guide to SCADA HMIs in .NET

An assembly line operator is not an ordinary user.

They work in noisy environments, sometimes wearing heavy work gloves, watching screens mounted at a distance, and making decisions in seconds. A valve closing abnormally, a temperature alarm exceeding a threshold, a motor reaching maximum speed: every signal has a precise meaning and every delay has a cost.

Building an interface for them is completely different from building any other software application. It is not about color palettes or polished animations. It is about safety, production, and responsibility. A button that is hard to press with gloves, an alarm that blends visually with others, a chart that updates with half a second of lag: these are not UX issues in the traditional sense, they are operational risks with measurable consequences.

Then there is the production manager. They want to see KPIs from the office, from a tablet in the meeting room, maybe even from home during a night-time stoppage. They need a different interface, more analytical, browser-accessible, without having to install anything on every workstation.

Two different users, two different needs, two opposite operational contexts. The .NET developer faces a concrete question: WPF or Blazor for SCADA HMIs? And the answer, as we will see, is not as simple as it seems.

In the industrial automation world, the choice of framework for the interface is never purely technical. It is a decision that affects plant life for years, sometimes decades. Operator panels are installed, configured, and then left in place, often without updates, until the machine itself is replaced. Making the wrong choice means ending up with an interface that works poorly in production, frustrated operators, process engineers asking for impossible changes, and unexpected maintenance costs.

This guide addresses a real question that .NET developers are asking more and more frequently: how do you correctly build an industrial HMI in 2026? Which technologies to choose, when to choose them, and above all, why.

You will find a direct comparison between WPF and Blazor with concrete use cases, the MVVM architecture applied to a real SCADA scenario, graphics libraries that truly hold up in production, and market opportunities for those who know how to do this work.

What Makes an HMI SCADA Interface Different from Any Other Application

Before comparing WPF and Blazor, we need to understand what type of interface we are building. Because an HMI SCADA is not just an application with a bit more data. It is a category of its own.

The term HMI, Human-Machine Interface, literally describes the interface between the human operator and the industrial machine. SCADA, Supervisory Control and Data Acquisition, is the broader system that collects data, historizes it, and enables supervision of the entire plant. The HMI is the "dashboard" of the SCADA: what the operator sees and interacts with.

Building an HMI means tackling challenges that exist in no other type of software application.

The first is high-frequency data updates. An industrial plant can generate tens, hundreds, or thousands of measurements per second: temperatures, pressures, flow rates, speeds, digital states. The HMI must receive this data, process it, and refresh itself without ever freezing. A UI freeze, even for a few seconds, can be enough for an operator to miss a critical alarm in time.

The second is symbolic plant graphics. Industrial HMIs show P&ID (Process and Instrumentation Diagram) schematics: graphical representations of the plant where every valve, pump, tank, and pipe is drawn in its real position. These elements change state in real time: a valve opens or closes, a tank fills or empties, a motor changes color based on its condition. There are no standard components for this type of graphics in any framework.

The third is prioritized alarm management. A professional SCADA system has hundreds of alarm conditions, classified by severity (critical, urgent, warning, informational), with acknowledgment logic, temporary silencing, and escalation. An operator cannot miss a critical alarm buried in a list of low-priority notices. The interface must guide their attention precisely.

The fourth is explicit command confirmation. When an operator clicks "Open valve V-101," the interface does not immediately execute the command. It first shows a confirmation dialog: "You are about to open valve V-101 on the cooling circuit. Do you confirm?" This is not a UX choice: it is a functional safety requirement for many industry regulations, including IEC 62061 and ISO 13849.

The fifth is the mandatory audit log. Every operator action, every command sent, every parameter changed must be recorded immutably: who did what, when, from which workstation, with what previous value and what new value. This is not a nice-to-have: in many sectors such as pharmaceuticals and food and beverage it is a regulatory requirement.

The end user of an HMI SCADA is not a developer: they are an operator with decades of experience on that specific machine, working in difficult conditions with no time to figure out a poorly designed interface.

Keeping this in mind is the difference between an HMI that truly works in production and one that operators start bypassing within three months of commissioning.

WPF for SCADA HMI: Strengths and When to Choose It

WPF, Windows Presentation Foundation, was introduced by Microsoft in 2006 and has remained the reference technology for desktop HMIs on Windows. Not out of inertia: for precise technical reasons that, even in 2026, no alternative framework has fully surpassed for the industrial use case.

The first strength is hardware-accelerated rendering via DirectX. WPF does not use GDI+ like old Windows Forms applications: it uses the graphics card to draw the UI. This means updating thousands of graphical elements simultaneously, such as a trend with 10,000 points or a plant schematic with 200 animated elements, does not load the CPU. The GPU does the heavy lifting.

The second is the data binding system with MVVM. WPF was designed for the MVVM pattern. The bidirectional binding between ViewModel and View, managed by the runtime, eliminates the need to write code to update the interface manually. When the ViewModel notifies a change via INotifyPropertyChanged, the View updates automatically. For an HMI with hundreds of tags, this is a huge architectural advantage.

The third is graphical flexibility. With WPF you can draw any custom graphical element using DrawingVisual for maximum performance or Path and Geometry for complex shapes. An animated valve, a tank filling with a smooth animation, a custom level indicator: all are achievable in XAML without external dependencies.

The fourth is native touchscreen support. Modern industrial operator panels are almost all touch. WPF has natively supported multi-touch gestures since 2010, with APIs to detect tap, slide, pinch, and rotate. No additional library is needed to make a WPF HMI fully operable via touch.

The fifth is integration with the Windows ecosystem. An industrial HMI on Windows can use integrated Active Directory authentication, access the registry for configuration, communicate with other processes via WCF or named pipes, and use Win32 APIs for low-level functionality. On WPF all of this is straightforward and well-documented.

For graphics libraries, the landscape in 2026 is mature. ScottPlot is the primary choice for SCADA trends: it handles millions of points, updates from background threads without UI freeze, and has a clean API. LiveCharts2 is better suited when visual presentation matters more than performance, such as in directional dashboards. Syncfusion and Telerik offer specific industrial components such as radial gauges, LED indicators, digital displays, and state machines that faithfully replicate the appearance of physical instruments.

WPF is the right choice when: the operator panel is a dedicated Windows PC, the update frequency exceeds 5 tags per second, plant graphics are complex and custom, network connectivity is not guaranteed (the HMI must work offline), and rendering performance is critical.

Blazor for SCADA HMI: The Web Entering the Factory

Blazor has changed the way of thinking about industrial interfaces. It does not replace WPF for high-frequency operational HMIs, but it opens a new space that previously required JavaScript or separate frontend frameworks: web-based SCADA supervision dashboards.

There are two variants of Blazor with very different characteristics for the industrial world. Blazor Server runs all application logic on the ASP.NET Core server and communicates with the browser via a WebSocket SignalR connection. The UI is updated in real time from the server: when data changes, the server sends the UI diff to the browser which updates accordingly. Blazor WebAssembly instead downloads the .NET application into the browser and runs it locally via WebAssembly, without server dependency for processing.

For industrial SCADA applications, the choice is almost always Blazor Server. The reason is simple: data comes from an industrial backend (OPC UA, PLC, time-series database) running on the server. With Blazor Server the data reading service and UI update live in the same process, eliminating a network round-trip. With Blazor WebAssembly you must add a REST API or gRPC layer between the browser and the industrial backend, increasing complexity and latency.

The main advantage of Blazor for industrial HMIs is multi-device accessibility without installation. A production manager can open a browser on any device, access the supervision dashboard, and see the plant state in real time. No client installation, no workstation configuration, no manual updates. This is a huge advantage over WPF in distributed supervision scenarios.

The main limitation of Blazor Server for HMIs is SignalR connection latency. Every UI update goes through: server processes the change, calculates the diff, sends the WebSocket message, browser receives the message, updates the DOM. This cycle typically takes 50-200 milliseconds on a corporate LAN network. For a manager looking at KPIs every 5 seconds this is irrelevant. For an operator monitoring a process with changes at 10 Hz, it is unacceptable.

The practical rule is: Blazor Server is suitable for updates up to 1-2 Hz, meaning when data refreshes every second or more slowly. Above this threshold, WPF is the correct choice.

Another advantage of Blazor is the ability to reuse components and business logic between the web application and API. A team that already knows ASP.NET Core is productive with Blazor Server quickly, without learning a new frontend framework.

Direct Comparison WPF vs Blazor for Industrial HMIs: The Decision Table

Comparing WPF and Blazor for SCADA HMIs means evaluating a set of criteria that depend on the specific context. There is no universal answer: there is the right answer for each use case.

Data update frequency. WPF updates the UI dozens of times per second without issue, limited only by the monitor refresh rate (typically 60 Hz). Blazor Server is practical up to 1-2 updates per second due to SignalR latency. WPF wins for operational HMIs, Blazor wins for dashboards.

Multi-device accessibility. WPF runs only on Windows desktop. Blazor runs on any browser, any operating system, any device. For remote or mobile supervision, Blazor has no alternative in .NET. Blazor wins without discussion.

Custom graphical complexity. WPF allows building any graphical element: animated valves, interactive plant schematics, radial gauges, digital displays. Blazor depends on JavaScript libraries for advanced graphics (Chart.js, D3.js via interop) or commercial components like Syncfusion Blazor. For complex P&ID schematics, WPF is still superior. WPF wins for industrial graphics.

Centralized maintenance and updates. With Blazor Server, updating the application means updating the server: all clients automatically receive the new version on next access. With WPF, every operator panel must be updated individually, which in a plant with 50 workstations is a real operational problem. Blazor wins for maintenance.

Offline operation. WPF continues working even if the network is unavailable: data arrives locally via OPC UA to the SCADA server on the same machine or local network. Blazor Server requires an active connection to the server: if the network goes down, the interface stops. WPF wins for scenarios with unstable connectivity.

Hardware cost for workstations. An industrial panel running WPF requires Windows, at least 4-8 GB of RAM, and an adequate processor. A Blazor client can run on an inexpensive thin client, an Android tablet, or an iPad: just a modern browser. For installations with many supervision workstations, Blazor significantly reduces hardware cost. Blazor wins for fleet cost.

The practical rule that emerges from these comparisons is clear: WPF for the line operator panel, Blazor for the managerial and remote supervision dashboard. In a professional SCADA project, both are often used together.

Implementing the MVVM Pattern in a WPF SCADA HMI: Project Structure

The MVVM pattern, Model-View-ViewModel, is not just a coding convention in WPF: it is the structure that makes an industrial HMI maintainable over time. A well-organized MVVM project allows changing the data reading logic without touching the interface, and changing the graphics without touching the application logic.

The layered structure of a professional WPF SCADA HMI project is organized as follows.

The lowest level is the OPC UA communication layer. It contains the service that connects to the OPC UA server, subscribes to the tags of interest, and receives change notifications. This layer is completely independent of the UI. When a value changes, it publishes an event or calls a callback. The reference library is OPC Foundation .NET Standard, available on NuGet.

Above the OPC UA layer sits the Model. The Model contains domain entities: the Tag class with its properties (name, current value, unit of measure, timestamp, data quality), the Alarm class with severity and acknowledgment state, the Machine class with its operational state. The Model knows nothing about WPF.

The ViewModel is the heart of the HMI. It implements INotifyPropertyChanged, exposes bindable properties to the View, and contains presentation logic. When it receives an update from the OPC UA layer, it must bring it to the UI thread before updating properties: in WPF, PropertyChanged notifications must always come from the UI thread.

The correct way to update the UI from a background thread is to use Dispatcher.InvokeAsync:

// In the ViewModel, when data arrives from OPC UA on a background thread
private async void OnTagValueChanged(string tagName, double newValue)
{
    await Application.Current.Dispatcher.InvokeAsync(() =>
    {
        ReactorTemperature = newValue;
        LastUpdate = DateTime.Now;
    });
}

For active alarm management, the ViewModel exposes an ObservableCollection that the View can filter and sort via CollectionView. Critical alarms must always appear at the top of the list, regardless of arrival order.

The View is the XAML that translates ViewModel properties into visual elements. Binding in WPF is powerful: you can bind not just values, but also element colors, visibility, and animations. An indicator that turns red when temperature exceeds a threshold is simply a binding with a Converter that transforms the numeric value into a color.

For operator commands, the ViewModel exposes ICommand objects (typically RelayCommand or AsyncRelayCommand from the CommunityToolkit.Mvvm library). The Command pattern in WPF separates logic from the button: the button does not know what happens when pressed, it only knows it must execute a command.

A fundamental practice for SCADA HMIs is to never block the UI thread. All I/O operations (reading from database, sending commands to PLC, writing the audit log) must be asynchronous. A UI thread blocked for 200 milliseconds waiting for a PLC response is an HMI that stops updating, and an operator who may miss a critical signal.

Real-Time Charts in WPF: ScottPlot and LiveCharts2 for SCADA Trends

The trend chart is probably the most critical component of a SCADA HMI. The operator looks at the reactor temperature chart for the last 30 minutes to understand whether the process is heading in the right direction. The maintenance manager looks at motor vibration trends to anticipate an impending failure.

The problem with real-time charts in WPF is the .NET garbage collector. A chart receiving 100 points per second and maintaining 10 minutes of history has 60,000 points to manage. If each point is a separate .NET object, the memory pressure is enormous, with resulting GC pauses that block the UI for tens of milliseconds. The solution is to use circular arrays of primitive types (double), not lists of objects.

ScottPlot is the library that solves this problem most directly. It is built exactly for this use case: scientific and industrial high-frequency charts in WPF and WinForms. Internally it uses pre-allocated double arrays and direct bitmap rendering. The result is a chart that updates at 60 Hz with 100,000 points without measurable CPU consumption.

Integrating ScottPlot into a WPF SCADA project is straightforward. The chart updates from a timer thread, not the UI thread, using the thread-safe Render method:

// Initialization in the ViewModel
private readonly double[] _timestamps = new double[36000]; // 1 hour at 10 Hz
private readonly double[] _values = new double[36000];
private int _nextIndex = 0;

// Add point (called by OPC UA service on background thread)
public void AddMeasurement(double timestamp, double value)
{
    _timestamps[_nextIndex % 36000] = timestamp;
    _values[_nextIndex % 36000] = value;
    _nextIndex++;
    TemperatureChart.Plot.Clear();
    TemperatureChart.Plot.Add.Signal(_values);
    TemperatureChart.Refresh();
}

LiveCharts2 takes a different approach. It uses a richer object model (series, points, axes with formatted labels) and produces visually more refined charts, with smooth animations and interactive tooltips. The cost is higher internal complexity and lower performance with very large datasets. LiveCharts2 is the right choice for WPF directional dashboards where presentation matters as much as performance, and for update frequencies below 5 Hz.

Syncfusion and Telerik offer components different from trend charts: radial gauges (the circular pressure gauges typical of industrial HMIs), linear gauges, bullet charts, digital displays, and animated state machines. These components faithfully replicate the appearance of physical instruments that operators are familiar with, reducing the interface learning curve. The cost is a commercial license.

To choose between ScottPlot and LiveCharts2, two criteria apply: if the update frequency exceeds 5 Hz or the dataset has more than 10,000 points, choose ScottPlot. If the frequency is below 5 Hz and chart aesthetics matter, LiveCharts2 is the better choice.

SCADA Dashboard with Blazor Server and SignalR: Architecture and Implementation

The web SCADA dashboard with Blazor Server has a three-tier architecture that is elegant for those who know ASP.NET Core. The background service reads industrial data, the SignalR Hub acts as a distribution channel toward connected clients, and Blazor components subscribe to updates and re-render the UI.

The background service is an IHostedService running continuously throughout the ASP.NET Core application lifetime. It reads data from OPC UA, a time-series database, or an internal SCADA API, and publishes changes to the SignalR Hub. The publication frequency is configurable: for a managerial dashboard, updating every 2-5 seconds is more than sufficient.

The SignalR Hub is the centralized distribution point. Blazor clients connect to the Hub and receive typed C# messages, without needing to write JavaScript. SignalR automatically manages reconnection in case of network interruption, with configurable retry logic.

The Blazor component showing, for example, machine status and OEE in real time implements IAsyncDisposable to correctly manage the Hub subscription:

The correct lifecycle is: OnInitializedAsync subscribes to the Hub and requests initial data, the callback method updates component properties and calls StateHasChanged() to force UI re-rendering, Dispose cancels the subscription to avoid memory leaks.

A typical use case for this architecture is the production manager dashboard: shows the status of all machines on the line (green = running, yellow = waiting, red = alarm), the overall OEE updated in real time, the last 10 alarm events, and the day's production KPIs such as parts produced and scrap.

This dashboard can be opened in any browser: the production manager consults it on their laptop in the office, the plant director opens it on a tablet during the production walkthrough, the quality manager monitors it remotely. No installation, no configuration, just a browser and access credentials.

Disconnection handling is a critical aspect that many overlook. When a Blazor Server client loses connection to the server, the session is maintained on the server for a configurable time (default 3 minutes) waiting for reconnection. During this time, state changes are queued. If reconnection occurs within the timeout, the client receives the updated state. If the timeout expires, the session is deleted and the client must navigate again. The interface must clearly communicate the connection status to the operator with a dedicated visual indicator.

Security and User Management in HMI SCADA Interfaces

Security in an HMI SCADA is not optional. In many sectors it is a regulatory requirement: FDA 21 CFR Part 11 for pharmaceuticals, IEC 62443 for general industrial automation, NERC CIP for energy infrastructure. Even outside regulatory obligations, an HMI without access control is an operational and security risk.

The standard access control model for industrial HMIs provides at least four user levels, with increasing permissions.

The Operator is the base level. They can view all plant data, acknowledge alarms, and execute standard production commands (start cycle, end shift, product selection). They cannot modify process parameters or system configuration.

The Supervisor has the same capabilities as the operator plus the ability to modify operational parameters within predefined ranges (temperature setpoints, line speed), silence specific alarms with recorded justification, and unblock process stalls.

The Process Engineer has access to all system parameters, including alarm thresholds, production recipes, and control logic configuration. This user can significantly change system behavior: every action must be recorded traceably.

The Administrator manages users, assigns roles, configures the authentication system, and has access to complete audit logs. They are the only one who can create new accounts or modify existing permissions.

For WPF, the most common authentication in industrial environments is integrated Windows authentication via Active Directory. The operator PC is on the corporate domain, the user authenticates at the Windows login, and the HMI automatically obtains credentials via WindowsIdentity. No separate login screen is needed. Roles map to AD groups.

For Blazor Server, ASP.NET Core Identity is used with integrated Windows authentication (if on corporate network with AD) or form-based authentication for remote access. The ASP.NET Core authorization middleware allows protecting pages and components with [Authorize] attributes and access policies.

The audit log is the cross-cutting requirement at all access levels. Every command sent to the machine must generate a log entry with at least these fields: precise timestamp (with timezone), operator username, workstation name, action performed, object identifier (tag or machine), previous value, new value, outcome (success or error). This log must be written to a separate database, ideally append-only, and must not be modifiable by HMI users even with maximum permissions.

A frequently overlooked aspect is the automatic session timeout. In an industrial plant, an operator may be called elsewhere leaving the panel unattended. If the panel remains open with the operator's active session, anyone approaching can execute commands under their credentials. Session timeout with re-authentication request after a period of inactivity is a simple but fundamental security measure.

Integrating WPF and Blazor in the Same SCADA Project: Hybrid Architecture

The practical question developers often ask is: can I have both? A WPF panel for the line operator and a Blazor dashboard for the manager, in the same project, with the same business logic code?

The answer is yes, and it is exactly the recommended architecture for professional SCADA projects in 2026.

The secret is correctly separating the layers. Business logic, meaning reading data from OPC UA, managing alarms, writing the audit log, and plant business rules, must live in .NET Standard libraries independent of any UI framework. These libraries are then consumed by both the WPF application and the ASP.NET Core application hosting Blazor Server.

The typical structure of such a solution in Visual Studio consists of these projects: a class library project for domain models (Tag, Alarm, Machine, AuditEntry), a class library project for services (OpcUaService, AlarmService, AuditLogService, HistoryService), a WPF project that consumes these services and builds the desktop HMI, an ASP.NET Core project with Blazor Server that consumes the same services and builds the web dashboard.

With this structure, the OPC UA communication code is written once and used by both applications. Alarm business rules, for example the logic whereby a critical temperature alarm remains active until acknowledged by an operator, are implemented once in the service layer and behave identically in the WPF HMI and Blazor dashboard.

The synchronization layer between the two interfaces can be implemented in various ways. The simplest is sharing the same database as the single source of truth: the WPF HMI writes the operator action to the database, the Blazor dashboard reads state from the database. More sophisticated is using an internal message bus like System.Threading.Channels or a lightweight queue system, so state changes propagate in real time to all consumers, both the WPF HMI and the Blazor dashboard.

A useful pattern in this context is the shared ViewModel: the same domain ViewModel, representing for example the state of a machine, is used by both the WPF layer and the Blazor layer. In WPF the ViewModel implements INotifyPropertyChanged for the UI. In Blazor Server, the Blazor component observes the same properties and calls StateHasChanged when they change.

This hybrid architecture is what distinguishes professional SCADA projects from one-size-fits-all approaches. It is not more complex to maintain: on the contrary, it reduces code duplication and ensures the two interfaces always show consistent data.

The Industrial HMI Market: Opportunities for .NET Developers

The Italian manufacturing market is the second largest in Europe by size, after Germany. Automotive, food and beverage, pharmaceuticals, petrochemicals, precision mechanics, utilities: these sectors manage plants worth hundreds of millions of euros that depend on supervision and control software written and maintained by specialized developers.

The structural problem is that these developers are few. The profile combining knowledge of .NET and C#, familiarity with industrial protocols (OPC UA, Modbus, Profinet), the ability to build HMIs in WPF and web dashboards in Blazor, and an understanding of the industrial operational context is a genuine rarity in the Italian job market.

Job offers for developers with these skills come from three types of companies. Specialized system integrators in industrial automation, such as certified Siemens or Rockwell partners, build custom SCADA solutions for their clients and seek .NET developers to add to software development teams. Contracts are typically project-based but often become long-term relationships for evolutionary maintenance.

Manufacturing companies with internal technical offices seek developers who can maintain and develop their proprietary SCADA systems. These positions are less visible on the market because they are often not advertised externally, but they offer stability and the opportunity to become the technical reference for the entire production.

SCADA software vendors such as Inductive Automation (Ignition), Aveva, Citect, and Italian companies in the sector such as Progea seek developers to extend their platforms with custom modules written in native .NET or Java languages.

Compensation ranges for .NET developers with HMI/SCADA skills in Italy are positioned significantly above the software sector average: 45,000-70,000 euros gross annually for profiles with 3-5 years of specific experience, with peaks above 80,000 euros for those with experience on critical plants in sectors such as pharmaceuticals or energy.

The difference compared to a generic .NET developer is the scarcity of supply combined with the criticality of the role. An industrial plant stopped due to a SCADA software problem costs thousands of euros per hour. Those who know how to solve it, or better yet prevent it, are valued accordingly.

Building this profile requires a specific path. Knowing C# and WPF is not enough: you need to understand how a PLC works, what a tag is and how to read it via OPC UA, how to structure an alarm system according to ISA-18.2 best practices, and how to design an HMI that an operator with 20 years of experience on that machine finds intuitive.

The starting point for many developers is building a personal project: a small PLC simulator with an OPC UA client written in C#, a WPF HMI with a real-time chart and some simulated alarms, a Blazor dashboard showing the same data in a browser. Physical PLC hardware is not necessary: free OPC UA simulators exist that allow developing and testing all communication logic without industrial hardware.

Those who already have this foundation and want to turn it into a structured career in industrial automation have ahead of them one of the most concrete and lasting opportunities in the Italian .NET market in 2026.