A protection test set should be specified as an evidence-producing system, not as a box with a certain number of current and voltage channels. The decisive question is whether it can reproduce the signals, logic transitions, communications and timing boundaries of the protection scheme while producing repeatable records that another engineer can review.
Begin with the protection applications
Build the requirement from the schemes to be tested: feeder overcurrent and earth fault, directional elements, transformer or bus differential, motor protection, synchronism check, autoreclose, breaker failure and any scheme using permissive or blocking signals. Record whether each scheme uses conventional 1 A or 5 A CT inputs, voltage inputs, low-energy analog inputs, IEC 61850 Sampled Values, hardwired binary I/O, GOOSE, or a hybrid combination.
Output capability is a burden problem
Maximum current alone is not enough. For electromechanical or older static relays, the test set must sustain the required current at the burden imposed by the relay and test leads. State the required apparent power and compliance voltage at the intended current. For numerical relays, accuracy and phase-angle performance at low current may matter more than extreme amplitude. Specify simultaneous output performance, because a headline value may apply only to one channel or a special parallel connection.
Timing and binary I/O
Define the number of independent binary inputs and outputs, wet/dry contact compatibility, voltage thresholds, time resolution and how contact bounce is handled. The test method must distinguish relay element pickup, relay output operation, trip-circuit energisation and breaker auxiliary-contact change. A single trip time without a clearly defined start and stop event is not auditable.
Digital-substation capability
For IEC 61850 projects, list the actual services: GOOSE publication/subscription, Sampled Values generation or analysis, MMS where required, editable datasets, SCL-file workflow, VLAN and priority handling, PRP/HSR compatibility and time synchronisation. IEC 61869-9 defines the digital interface for instrument-transformer measurements; the test plan must validate dataset mapping, scaling, quality and time behaviour—not merely prove that Ethernet frames are present.
Parameter-based and system-based tests
Parameter-based tests verify individual characteristics against settings and tolerance. System-based tests inject realistic network events and assess the complete scheme response. Neither replaces the other: the first provides detailed element evidence; the second is stronger at finding polarity, logic, coordination and model-integration errors. Require a workflow that preserves settings, test model, firmware, connections, results and deviations in one controlled report.
Safety and cybersecurity
Specify visible output-state indication, emergency shutdown where required, protected voltage leads, safe isolation of test circuits and a connection philosophy that prevents accidental CT open circuits or VT shorts. For networked test sets, require authenticated devices, encrypted management channels, controlled software updates, vulnerability handling and a defensible method for moving files between corporate and substation environments.
Acceptance checklist
- Demonstrate the worst required analog burden and the lowest accuracy point.
- Run a representative multi-element automated test and export a reviewable report.
- Prove GOOSE/SV interoperability using the project SCL files where applicable.
- Verify calibration traceability and the uncertainty statement for critical quantities.
- Check field weight, connector robustness, boot time, support lifecycle and offline usability.
- Confirm that software licensing and test templates remain usable over the expected fleet life.
What a datasheet does not prove
A channel count does not prove that all channels can deliver the required amplitude, burden and accuracy simultaneously. Protocol support does not prove interoperability with the project configuration. Automated templates do not prove the protection philosophy is correct. These claims must be converted into witnessed acceptance tests.
Official sources and revision control
- OMICRON CMC 500 official product page
- Doble F6150sv official product page
- Megger RTMS official software page
- IEC 61869-9:2016 official record
- IEC TS 60255-216-1:2025 official record
Technical review date: 16 August 2026. Standards and product capabilities can change; confirm the project-specific edition, firmware, options and ordered configuration before engineering or procurement.