The direction of travel
MV protection is moving from one dedicated relay per bay toward software-oriented architectures: distributed process interfaces acquire current, voltage and switch status; centralized or virtualized applications execute protection/control; standardized communications connect them; and higher-level analytics use event and condition data. The opportunity is flexible lifecycle management and system-wide functions. The risk is concentrating many zones into shared computing, network, time and configuration infrastructure.
1. Architectural spectrum
| Architecture | Where protection runs | Main trade-off |
|---|---|---|
| Conventional bay IED | Dedicated relay in each panel with local CT/VT and hardwired trip. | Simple failure containment; more hardware/wiring and distributed maintenance. |
| Centralized physical controller | One or redundant substation devices protect multiple bays; bay units handle process I/O. | Efficient system view, but shared hardware/network needs strong redundancy and partitioning. |
| Virtualized protection | Protection software runs on industrial compute/virtual platform with process interfaces. | Software deployment flexibility; deterministic scheduling, platform qualification and cyber/lifecycle control are critical. |
| Hybrid | Critical primary functions local; backup/automation/analytics centralized. | Practical migration and diversity, but interfaces and ownership must be explicit. |
2. Centralized protection benefits
- Access to all bay currents, voltages and statuses enables bus, feeder and topology-aware functions.
- Fewer high-function bay devices and standardized process interfaces can simplify expansion.
- System settings, logic and records can be managed centrally.
- Spare compute capacity can support new functions without replacing every panel IED.
- Cross-bay testing and automation become more consistent.
These benefits are real only if the architecture retains required independence. One central controller that replaces 30 relays without redundant compute, process I/O, network, time and power may reduce component count while increasing outage consequence.
3. Virtualization engineering requirements
Protection is real-time. The platform must guarantee CPU, memory, network and storage resources; bound scheduling and interrupt latency; control other workloads; synchronize time; survive host/network failures; and recover without unsafe output states. Define hypervisor/container/runtime, hardware, firmware, operating-system patch policy and application version as one qualified platform.
Use active/standby or other proven redundancy with deterministic state and output ownership. Test failover during fault inception, not only at idle. A virtual-machine restart measured in seconds is not acceptable for a primary protection gap unless independent protection remains active.
4. Digital twin: three different meanings
| Twin type | Useful purpose | Evidence limit |
|---|---|---|
| Engineering twin | Executable model of logic, SCL, settings and network. | Supports FAT/change testing; must match as-left field configuration. |
| Asset/condition twin | Model using breaker travel, coil current, temperature or operation history. | Can identify degradation trends; does not itself prove interrupting capability. |
| Power-system real-time twin | Dynamic/EMT model connected to protection hardware/software. | Tests rare faults and topology states; validity depends on model and interface accuracy. |
Call a model a twin only when identity, synchronization and change control connect it to the physical asset. A one-time simulation file is not a maintained digital twin.
5. AI-based diagnostics
Machine learning can rank alarms, identify unusual breaker coil/travel signatures, classify waveform events, predict cable/asset issues and assist root-cause analysis. It is best introduced as decision support with human review. Training data must represent the actual equipment and fault population; class imbalance and changing firmware/equipment can cause model drift.
For any AI output define confidence, explainable evidence, false-positive/false-negative consequence, retraining/version process and fallback. Do not allow an unvalidated adaptive model to modify trip settings autonomously in a safety-critical scheme.
6. Standards and interoperability
IEC 61850 and IEC 61869 support standardized data models, GOOSE, Sampled Values and SCL. IEC TS 60255-216-1:2025 is important because it addresses protection functions with digital inputs/outputs and related functional testing. IEC 61850-10 and IEC TR 61850-10-3 cover conformance/system testing aspects. Interoperability still requires project testing: standards conformity does not guarantee identical vendor interpretation of every optional behavior.
7. Reliability model
Perform failure-mode and common-cause analysis across sensors, merging units, I/O, networks, clocks, central compute, application instances, DC power and engineering configuration. Separate availability (function running), dependability (trips when required) and security (does not trip incorrectly). Redundancy can improve availability while shared configuration reduces security.
| Failure | Required design question |
|---|---|
| One merging unit fails | Which zones lose measurements, and is independent backup active? |
| One network/path fails | Is there zero-recovery redundancy and a visible degraded alarm? |
| Central compute fails | How fast and deterministically does standby own outputs? |
| Wrong system configuration deployed | Can signatures, approvals, staged rollout and rollback prevent station-wide impact? |
| Time source compromised/lost | Which functions continue, block or degrade? |
| Cybersecurity patch required | How is it tested against real-time performance and rolled back? |
8. Testing strategy
- Unit-test each protection function against standard and application cases.
- Integration-test process I/O, SV/GOOSE, time, output and SCL configuration.
- Run hardware/software-in-the-loop fault scenarios for all topologies.
- Load/stress test compute and network with one redundancy path failed.
- Inject failures during fault processing and verify failover/no double trip.
- Validate cybersecurity controls, signed packages, roles and audit logs.
- Repeat a defined regression suite after every platform, application or configuration update.
- Perform field end-to-end tests to actual breakers and preserve results.
9. A sensible migration roadmap
- Standardize naming, settings management, time synchronization and event collection in existing IEDs.
- Introduce IEC 61850 GOOSE for selected supervised non-critical or backup functions.
- Deploy LPIT/process bus in a pilot bay with conventional independent backup.
- Centralize cross-bay automation or backup protection before primary functions.
- Validate central/virtual primary protection with a full regression and failure-injection program.
- Retain a rollback and spares plan through each lifecycle phase.
10. Procurement questions
- What is the guaranteed worst-case protection execution and failover time under full load?
- Which hardware/software combination is type-tested and how are updates qualified?
- How are applications isolated so one failure cannot corrupt all bays?
- What independent backup remains during compute/network maintenance?
- Which IEC 61850/61869 profiles, SCL revisions and cybersecurity functions are supported?
- How are configuration signatures, audit logs, rollback and long-term licenses handled?
- What test harness and digital twin are delivered to the owner?
- What is the 15–25 year migration/obsolescence plan?
Related protection guides
Engineering limitation
This guide explains a defensible engineering workflow; it is not a project setting calculation. Final protection functions, settings, wiring and trip logic must be based on the approved single-line diagram, short-circuit and coordination studies, equipment data, grid code, relay manual, and verified commissioning results. Changes require formal protection-management control.
References and further reading
- IEC TS 60255-216-1:2025 — digital I/O protection requirements and functional interoperability tests
- IEC TR 61850-10-3:2022 — system testing of IEC 61850 applications
- ABB Digital Substation / centralized protection — SSC600/SSC600 SW architecture and current offering
- CIGRE Paris Session 2024 technical programme — field work on centralized/virtualized protection and process bus testing
- CIGRE — Protection for modern distribution networks — future distribution protection scope and DER challenges
Standards must be applied using the edition required by the project, utility and local law. Standards summaries on public pages are not substitutes for the controlled documents.