If you tried to pick the one theme that stood out most clearly on the exhibition floor of CIGRE 2026 in Paris, for us it was the virtualisation of protection.
And this is no longer about a single experimental product or a nice concept on slides. Over a few hours of walking the show, we met this theme at the stands of ABB, Siemens, Moxa, Welotec, Kalkitech and others. Some companies offer virtualised protection functions directly, others the servers those functions are meant to run on, and others still assemble near-ready multi-vendor architectures from the components of different manufacturers.
And the more we talked with company representatives, the more obvious it became: the key question here is no longer «can protection run in a virtual machine?». Of course it can. A far more interesting question is: who now defines the hardware architecture and answers for the reliability of this whole computing platform?
ABB: protection finally separates from the «iron»
One of our first stops was the ABB stand.
Centralised protection is not new for ABB. Its portfolio has for several years included the SSC600 — a device in which protection and control functions, traditionally distributed across the terminals of individual bays, are centralised at the substation level.
The next step was the SSC600 SW. Here, only the software implementation remains of ABB's dedicated hardware platform. ABB officially describes the SSC600 SW as a purely software product, delivered as a virtual machine and intended to run in KVM and VMware environments; the customer can use the hardware platform of their choice.
The conversation with ABB's representatives turned out to be especially interesting.
The delivery logic looks roughly as follows: the software image for deployment on a virtual machine can be obtained separately, and the required functionality is then activated by licence. According to the company's representatives at the stand, a build for use on the open SEAPATH platform is also being prepared.
But it was not even that that mattered most.
ABB abstracts almost entirely away from how exactly the customer will build the computing infrastructure. The company is ready to formulate server performance requirements depending on the number and mix of implemented functions, but the choice of the specific hardware architecture is left to the system integrator and the customer.
Moreover, we asked separately whether there are any fundamental restrictions on placing other applications on the same physical server. The answer was no. On neighbouring virtual machines you could run, for example, SCADA, a communication controller and even virtualised protection functions from other manufacturers.
And here the flip side of hardware independence appears.
To the question of exactly how a fault-tolerant server architecture should be built, we did not get a clear-cut answer. Redundancy of the computing nodes, a continuous/high-availability architecture, behaviour on the failure of a physical server — all of this is no longer inside the ABB product but becomes a matter of designing the system as a whole.
This is a rather fundamental shift in the boundary of responsibility.
In a traditional protection terminal, the device developer controls the processor, the operating system, the hardware interfaces and a significant part of the reliability mechanisms. In the virtualised world, the manufacturer provides the protection functions as software plus requirements for the execution environment. And the fault tolerance of the whole platform now has to be designed by the integrator in line with the end customer's requirements. In fact, the customer here can already define a standard hardware platform — and not only the hardware but also the software, in terms of the virtual-machine deployment environment, their number and so on.
Another interesting ABB exhibit complemented this picture well — the compact REX600, which receives signals from low-power instrument transducers and performs the functions of an analogue-signal converter. The device can also perform local backup-protection functions. ABB positions it as an element that integrates with the SSC600 and SSC600 SW; it supports, among others, IEC 61869-9 and IEC 61869-13.
The result is a very characteristic architecture: a relatively simple process interface stays near the primary equipment, while the main computing functions move to a centralised platform.
Moxa: if protection has become software, where will it run?
From ABB's representatives we got the names of two hardware-platform makers already used or considered by customers for such tasks: Moxa and Welotec.
So the next stop, quite naturally, was the Moxa stand.
And almost at the centre of the display was indeed the DA-920E — a new fanless server (of the passively cooled type), positioned by the company specifically as a platform for Virtual Protection, Automation and Control — vPAC.
This is no longer an ordinary industrial computer. The DA-920E comes in a 2U form factor and meets the requirements of IEC 61850-3, IEEE 1613 and IEC 60255. At its core is an Intel Xeon D-1834 with 8 cores and 16 threads; up to 256 GB of ECC RAM is supported, four 2.5-inch SSDs with RAID and a separate NVMe drive, plus PCIe expansion. Moxa links this product directly with the transition to virtualised protection.
Here the formation of a new market is especially palpable.
A protection manufacturer no longer necessarily has to develop its own dedicated computing unit. Independent hardware platforms are appearing, designed specifically for operation directly at power facilities.
That is, the movement is not from dedicated equipment straight to an ordinary data-centre server. Rather, an intermediate class of devices is forming: a standard x86 architecture, but in a build designed for the electromagnetic environment and operating conditions of a substation.
However, the most unusual Moxa exhibit for us was not the server at all.
At the stand they were showing a prototype of a GNSS/GPS receiver built in an SFP form factor. An external antenna connects to the small module, which is then installed directly into the SFP slot of a compatible switch. The idea is that such a module lets the switch itself act as a precise-time source and PTP Grandmaster without a separate time server.
For small substations the idea looks extremely attractive: the separate synchronisation device literally «collapses» into an SFP module.
But for now it is exactly a prototype. And if it becomes a real product, the main question will no longer be its impressive form factor but the maturity of the implementation. How flexibly will the PTP profiles be configured? How will the device behave on loss of GNSS? How will synchronisation be recovered? How stably will it operate in various transient regimes?
This is the case where a very elegant engineering idea still has to prove its fitness for real operation.
Welotec: the whole architecture in one cabinet
At the Welotec stand we saw not a single element but a practically assembled demonstration of what a multi-vendor virtual protection can look like.
At its core was the RSAPC Mk2 — Rugged Substation Automation Computer. This is also a fanless 2U substation-grade server with IEC 61850-3 and IEEE 1613. In the maximum configuration it uses an Intel Xeon W with 8 cores and 16 threads; the stated temperature range is from −40 to +70 °C. Welotec offers various operating environments for this platform, including VMware ESXi, Red Hat Enterprise Linux Real Time and, especially interestingly, a pre-installed LF Energy SEAPATH.
But far more important than the server's specs was the demonstration architecture itself.
On a single infrastructure, the components of several manufacturers were combined. SEAPATH served as the virtualisation platform, an ABB solution was demonstrated as the virtualised protection, and next to it ran the zenon SCADA/HMI by COPA-DATA. The network infrastructure was represented by Westermo, and time synchronisation — including Hopf equipment.
In effect, the «Multi Vendor vPAC Demo Setup» sign at the Welotec stand turned out to be one of the most telling images of the whole show.
It shows the main change: substation automation is potentially turning from a set of finished devices by individual manufacturers into an integrable computing system.
The server may be made by one company. The hypervisor or virtualisation platform — by another ecosystem. The virtualised protection devices — by a third. The SCADA — by a fourth.
There is far more freedom.
But at the same time it becomes much harder to answer the question: who is responsible for the result as a whole?
The presence of two power supplies, RAID, PRP/HSR or redundant network interfaces does not in itself mean the fault tolerance of a virtualised protection system. You have to define the possible failure domains, the redundancy strategy for the computing nodes, the acceptable function-recovery time, the behaviour of the virtual machines on failures and the requirements for updating the infrastructure software.
In other words, virtualisation shifts a significant part of the engineering complexity from the individual IED up to the level of the system architecture.
Kalkitech: the next step — the software-defined substation
At the Kalkitech stand we ran into the same theme again, but here it was framed even more broadly — Software Defined Substation.
The demonstration architecture used the SYNC server platform, a bare-metal hypervisor and several virtual machines. On the diagram, virtual protection functions sat side by side, including Kalkitech's own VPR and ABB's SSC600 SW, and above them — other automation applications.
Kalkitech has long been developing the Virtual Protection Relay concept and offers its own IEC 61850 VPR Framework. It includes subscription to Sampled Values, MMS, GOOSE, SCL configuration, reference protection functions and interfaces for plugging in third-party algorithms.
And whereas at the ABB stand we talked first of all about the virtualisation of protection, Kalkitech poses a broader question: if protection can already be applications, why should SCADA, gateway, HMI, monitoring and other functions necessarily remain separate physical devices?
After four different stands — ABB, Moxa, Welotec and Kalkitech — the coincidence is already hard to call accidental. A full-fledged technological ecosystem is beginning to form around virtualised protection.
Siemens: virtualisation — yes, but under the manufacturer's control
Against this backdrop, the Siemens approach looks especially interesting.
The company also demonstrates virtualised protection — SIPROTEC V, using the proven SIPROTEC 5 algorithms. Siemens claims scaling to 60 virtual IEDs on a single computing platform.
However, the commercial model differs noticeably from ABB's approach.
Siemens also uses the term «hardware independent», but hardware independence here is limited to a list of approved, or whitelisted, substation-grade server platforms. Moreover, Siemens speaks directly of a «packaged approach»: the customer is to be supplied a hardware/software bundle, where SIPROTEC V and the operating system are already pre-installed on validated equipment.
And this is perhaps one of the most interesting takeaways from the walk around the show: even within a single trend, manufacturers choose different models.
ABB's approach can loosely be described as «protection as software». The manufacturer gives a software product and the compute-resource requirements, while a significant part of the system architecture is left to the integrator.
Siemens's approach is closer to «virtualised protection as a validated system». The protection software is already separated from the traditional IED, but the manufacturer continues to control the combination of the software and hardware platforms.
Which of them turns out to be closer to the future mass architecture of digital substations is far from obvious yet.
Arteche: a technology that never went mainstream
Against the very dynamic story of virtualisation, the Arteche stand looked unexpectedly contrasting.
There, an optical current transformer, the SDO-OCT — a solution based on the Faraday effect — was presented. The instrument transducer is entirely passive, and the active electronics are moved into an electronic unit that can produce Sampled Values in accordance with IEC 61869-9.
The principle itself is far from new. Similar devices were shown at industry exhibitions many years ago. So we were especially curious to ask Arteche's representatives: how far has the market moved in that time?
The answer was rather sobering.
According to the company's representatives, the scale of optical current transformer deployment still remains extremely small. Moreover, several manufacturers that worked with this technology have, in their estimate, closed the corresponding lines altogether.
And visually the exhibition did not contradict this impression: over the course of our walk, the Arteche optical CT turned out to be just about the only such exhibit that caught our attention.
An interesting contrast emerged.
The secondary systems are moving fairly quickly towards a software-defined architecture, virtualisation and independent computing platforms. But the revolution in primary instrument transducers, which the industry was promised many years ago, is so far proceeding much more slowly.
Technological appeal and mass adoption, as we know, are far from always the same thing.
Hopf: 30 kilometres between the antenna and the clock
Another unexpected discovery for us was the company Hopf. We first noticed it in the Welotec multi-vendor demonstration, where its equipment was used in the time-synchronisation system, after which we decided to visit its own stand.
Hopf specialises in unified-time systems. At the stand, various time servers were presented, including highly stable versions with rubidium oscillators.
But what most caught our attention was a small component of the antenna system.
It is a converter that lets the signal between a GNSS antenna and a time server be carried over optical fibre. A range of up to 30 km was stated at the stand.
At first glance this is a rather niche device. But from the point of view of a real facility the idea is very interesting.
In the ordinary case the length of a GNSS antenna's coaxial path is limited by attenuation. Even in Hopf's own documentation for its antenna systems, a standard cable is limited to tens of metres, and with certain cable types and amplifiers we are talking about hundreds — but not tens of thousands — of metres (though such cables are no longer as flexible).
Moving to fibre fundamentally changes the situation.
The antenna can be placed at a significant distance from the protected facility — for example, where the view of the satellite sky is better or the siting requirements are easier to meet. At the same time, the long conductive path between the external antenna and the equipment inside the building disappears, which is also interesting from the standpoint of galvanic isolation and lightning protection.
This is a good example of the fact that the truly interesting things at a big exhibition are far from always in the centre of the stand.
What the exhibition showed in the end
After walking these stands, our main conclusion is not that «virtualised protection has appeared». That idea has been around for years.
Something else has changed: a market is beginning to appear around it.
There are functions as applications from ABB and Siemens. There are dedicated computing platforms from Moxa and Welotec. There is the open SEAPATH environment. There are companies like Kalkitech that already see virtualisation as the basis of a broader Software Defined Substation. Multi-vendor demonstrations are appearing, where the products of different manufacturers really do work inside a single architecture.
Which means the next stage of development will be about systems engineering rather than about proving the fundamental workability of virtual protection.
How do you make the computing platforms redundant? How do you define the acceptable failure domains? Can SCADA and protection be placed on the same physical servers? Who is responsible for updating the hypervisor? How do you validate the system after a change of infrastructure? Where does the boundary of responsibility run between the supplier of the protection functions and the system integrator?
On a classic digital substation, one of the key objects of engineering design was the IEC 61850 network.
It looks as if a software-defined substation gains one more such object — the computing infrastructure itself.
And it may be precisely here that lies the main shift you can see at CIGRE today.
Protection is gradually ceasing to be only a device.
It is becoming a software function.
And with that, the end customer, the designer and the system integrator will have to learn to design not only the protection, the network and the synchronisation system, but also the platform on which that protection lives.