Testing

Testing protection schemes when the signals arrive over the network

2026-10-29 · 7 min read

A test set with leads injects currents and voltages into a relay, and the relay trips a contact you can measure. When the signals arrive as network traffic, every one of those steps changes: injection becomes publishing, the trip becomes a message, and "did it work" becomes a question about timing and about who else was listening.

Injecting analogue quantities as SV

The test set publishes sampled values that mimic a merging unit. The device under test subscribes exactly as it would in service, which is the point: you are testing the whole path, not a simulated analogue input.

The practical requirements are alignment and labelling — the published stream must use the dataset and identifiers the device expects, and must be aligned to the station time base. A test that injects the right numbers with the wrong identifiers proves nothing.

Testing GOOSE intertrip

An intertrip is a GOOSE message that may carry no data your test set can measure with a lead. What you measure instead is the time from publication to the receiving device acting, and you measure it on both ends.

• Capture on the publisher and on the subscriber, and compare timestamps. The difference is the time you are claiming.
• Test the failure direction: what the receiver does when the stream stops. A scheme that only trips correctly while the network is healthy is not a scheme.
• Test with a second publisher on the same VLAN, so a wildcard subscription is caught during testing rather than during a fault.
• Test the test flag: a commissioning message must not trip anything, and this is worth proving on the real hardware at least once.

Isolating test traffic

In a copper world, a test set is connected to one device. In a network world, publishing into a shared bus affects everyone subscribed, and a mistake during testing can reach equipment in service. Before the test, decide and document: separate VLAN, dedicated test port, or a device test mode that suppresses real outputs.

What to capture and keep

• The published stream and the received stream, with timestamps, for at least one operation of each type.
• The device event log, so protection and communication events can be correlated.
• The measured operate time and the means by which it was measured — a number without a method is not evidence.
• Version of the test set, the configuration used, and the SCL files of both ends.

The failure that surprises people

Protection operation is correct and the communication of it is late or lost. The relay tripped, the breaker opened, and the sequence-of-events record shows the operation later than it happened or not at all — because the report was queued behind a flood of lower-value events. Test the reporting path under load, not just on an idle bench.

Questions that come up

Can we test with conventional injection into the relay instead?

For protection algorithm testing, often yes. It does not test the process bus, the time alignment or the GOOSE path — which are precisely the new failure modes.

How accurate can a GOOSE timing measurement be?

As accurate as your capture point and clock. Timestamping at the NIC is the practical requirement; software timestamps on a busy machine add jitter of the same order as the quantity you are measuring.

Do we need to test with the real merging units?

Not for every test, but at least once for interface and alignment verification. Simulators agree with your assumptions; the real device is where the assumptions are tested.

Keep reading