vPAC stands for Virtual Protection, Automation and Control. It describes the protection, automation, and control functions of a substation that run as virtual machines or containers on a ruggedized industrial server rather than on dedicated protective relays. The prerequisite is a digital substation built to IEC 61850.
Related and interchangeable terms: virtualized protection, virtual IED (vIED), virtual protective relay, software-defined substation, substation computing.
What Changes Relative to the Conventional Architecture
The conventional rule is one function, one device. Distance protection is a box. The bay controller is the next. The telecontrol gateway is another. Each of these IEDs (Intelligent Electronic Devices) brings its own hardware, its own lifecycle, and, sooner or later, its own spare-parts problem.
The arithmetic behind it is where this gets uncomfortable. Primary plant runs for 30 to 40 years; the hardware of the secondary system perhaps 12 to 15. Over the life of a substation, that means several complete replacements, each one carrying its own re-engineering and testing effort.
vPAC decouples function from hardware. The protection function itself does not change in engineering terms; it simply runs somewhere else - as software, on a shared server. The enabler is the digital substation to IEC 61850: merging units digitize current and voltage out in the bay, Sampled Values and GOOSE travel over the process bus, and the application no longer needs hardwired terminals of its own.
| Characteristic | Conventional architecture | vPAC architecture |
| Execution environment | a dedicated, often multifunctional protective relay per bay | virtual machine or container on a server |
| Software / hardware coupling | fixed and permanent | decoupled; each side can be replaced on its own |
| Process interface | copper wiring or process bus | process bus per IEC 61850 (Sampled Values, GOOSE) |
| Adding a function | expansion module or additional device, plus wiring and panel space | a software instance (VM or container), provided spare compute capacity is available |
| Replacing hardware | the application goes with the box; re-engineering follows | swap the server; the application stays |
Table 1 — Conventional protection, automation, and control architecture compared with vPAC.
The economic case for vPAC therefore rests on a single point: software and hardware can be refreshed independently of one another. The panel space saved is a bonus, not the argument.
The Real-Time Requirement: GOOSE and Sampled Values Are Two Different Problems
Real-time performance is where vPAC succeeds or fails. And two data streams get lumped together here routinely, even though they behave nothing alike.
GOOSE (Generic Object Oriented Substation Event) is event-driven. Something happens, a message goes out, it arrives. The figure of merit is end-to-end transfer time - through the protocol stack, the hypervisor, and the switch. Most of the time nothing happens at all, and it is out of exactly that idle state that the system has to respond immediately.
Sampled Values (SV) are the opposite: a continuous, fixed-rate stream that never stops. Under the protection profile of IEC 61850-9-2LE - an implementation guideline published by the UCA International Users Group rather than an IEC standard in its own right - a merging unit publishes 80 samples per power system cycle. At 50 Hz that works out to 4,000 frames per second, one every 250 microseconds. Newer installations increasingly follow IEC 61869-9, which specifies the sampling rates normatively: 4,800 Hz and 14,400 Hz for 50 Hz systems, equivalent to 96 and 288 samples per cycle. The order of magnitude does not change. With several merging units per bay, the count climbs into the tens of thousands of packets per second, all of which a single server has to process without loss and in the correct order.
And this is where the real difference lies: with Sampled Values, average latency is not the metric that matters. The subscriber aligns incoming samples by sample count and timestamp and buffers them, so network jitter is absorbed - but it is paid for out of the latency budget, and the buffer has a finite depth. What actually breaks the algorithm is packet loss, and reordering beyond the buffer window. A protection algorithm running on a signal with gaps in it is worthless - it still computes, it just computes the wrong answer.
| Data stream | How it behaves | What matters | Why this is hard for a server |
| GOOSE | event-driven, irregular | end-to-end transfer time | rare events must get through immediately, with no advance warning |
| Sampled Values (protection profile) | continuous stream, 80 samples per power system cycle, one every 250 µs at 50 Hz< | jitter and packet loss | sustained load over hours and days without a single dropout |
| Sampled Values (measurement profile) | continuous stream, 256 samples per power system cycle | jitter and packet loss | the same requirement at a higher sample rate; the frame rate is lower because each frame carries multiple measurement payloads |
| Time synchronization | continuous | accuracy against the common time reference, roughly ±1 µs | without a common time base, samples from different merging units cannot be combined (IEC 61850-9-3, PTP profile of IEEE 1588) |
Table 2 — The four time-critical data streams of a digital substation and what each one demands of the platform.
What Platform vPAC Requires
A standard data center server will not do the job. The platform has to provide:
- Hardware qualified to IEC 61850-3 and IEEE 1613, for temperature range, EMC immunity, and vibration in the substation environment
- A real-time kernel, CPU pinning, and isolated cores for the time-critical virtual machines
- Network interface cards supporting direct PCIe passthrough and SR-IOV, with hardware timestamping passed through to the virtual machine (bypassing hypervisor virtual switching for low-latency Sampled Values processing)
- A high-availability cluster with automatic failover for the functions that tolerate a restart: bay control, telecontrol gateway, HMI
- Redundant protection instances running in parallel on physically separate nodes — cluster failover takes seconds, which is orders of magnitude too slow for a trip decision, so protection continuity follows the same main 1 / main 2 logic as a conventional scheme
- Network redundancy to IEC 62439-3, PRP or HSR, on the process bus — Sampled Value streams carry no retransmission mechanism, so a lost frame is lost unless the network itself delivers a second copy
- Hardening to IEC 62443 for the systems and IEC 62351 for the communications
Virtualization in the substation is therefore not a consolidation project. It is a real-time engineering project that also happens to save hardware.
What vPAC Is Not
vPAC is not a product and not a vendor
It is an architectural concept, and different suppliers implement it in different ways.
vPAC is not a standard
No standard carries the name “vPAC.” The normative basis is IEC 61850, supplemented by IEC 62443 and IEC 62351.
vPAC is not the same as centralized protection (Centralized Protection and Control, CPC)
In a centralized protection scheme, many functions move into a single physical device, and the information flow between them becomes internal to that device. Under vPAC, the functions remain separate instances and their IEC 61850 communication stays visible on the wire — they simply run on shared hardware.
vPAC is not identical to the vPAC Alliance
vPAC is the technical concept. The vPAC Alliance is an industry consortium that defines a reference architecture for it.
Facts at a Glance
- Meaning of the abbreviation: Virtual Protection, Automation and Control
- Normative basis: IEC 61850, supplemented by IEC 62443 and IEC 62351
- Environmental requirements for the hardware: IEC 61850-3, IEEE 1613
- Time synchronization: PTP to IEEE 1588 with the power utility profile of IEC 61850-9-3, roughly ±1 µs
- Sampled Value rate: one frame every 250 µs at 50 Hz in the IEC 61850-9-2LE protection profile; IEC 61869-9 specifies 4,800 Hz and 14,400 Hz normatively
- Economic driver: primary plant 30 to 40 years, secondary system hardware 12 to 15 years
