How Can You Test IEC 61850 GOOSE Virtual Wiring in Digital Substations?

IEC 61850 GOOSE virtual wiring is tested by comparing the engineered signal path with live Ethernet traffic, then injecting controlled GOOSE state changes to prove each subscribed IED responds correctly. A reliable test combines SCL-file validation, mirrored-port packet capture, sequence-number checks, end-to-end timing measurement, and controlled output verification before energization.

The Complete Guide to Secondary Injection Testing for Digital Substations

What Is GOOSE Virtual Wiring in a Digital Substation?

GOOSE virtual wiring replaces copper interposing wires between protection relays, bay controllers, switchgear interfaces, and other IEDs with Ethernet multicast messages. Each virtual wire must be proven from its source data point to the correct subscriber logic, output, alarm, or interlock.

In a conventional substation, a trip command may travel through a physical terminal block, multicore cable, auxiliary relay, and breaker trip coil. In a digital substation, that same functional path can include:

• A protection IED logical node.

• A GOOSE dataset member.

• A GOOSE control block.

• An Ethernet switch and VLAN path.

• A subscribing IED or switchgear interface unit.

• Internal logic and an output contact.

The key commissioning question is not simply “Is the packet visible?” It is: “Does the correct protection condition create the correct Ethernet state change, reach the intended subscriber, pass all permissive logic, and operate only the intended output?”

In our production support work, we have seen a GOOSE frame that looked completely healthy in a packet capture but still failed functional testing because the subscriber referenced an old dataset revision. The network path was correct; the engineering path was not. That is why virtual wiring testing must verify communications and application behavior together.

How Should Engineers Prepare GOOSE Tests Before Packet Capture?

Prepare by freezing the approved SCL engineering baseline, creating a signal matrix, and defining safe test states for every trip, block, alarm, and interlock. Packet capture should begin only after the expected publisher, subscriber, dataset, VLAN, MAC address, and output behavior are documented.

A practical test matrix should list every critical virtual signal, including:

• Publisher IED and logical device.

• GOOSE control block reference.

• Dataset member and expected data type.

• Subscriber IED and internal logic destination.

• VLAN ID, Ethernet priority, and multicast MAC address.

• Expected response time.

• Expected physical contact, LED, HMI indication, or report.

• Reset and fail-safe behavior.

The SCD file is the baseline, but it is not the final evidence. During factory acceptance testing, a common problem appears when a late design change modifies a relay configuration but the project team distributes an earlier CID or ICD file. The engineer sees the correct signal name in a worksheet, while the relay publishes a different dataset order or configuration revision.

At Wrindu, we recommend assigning each GOOSE test case a unique signal ID such as “TRIP-21A-001.” Use the same ID in the engineering matrix, packet-capture annotation, test report, and final handover record. This removes confusion when several bays contain similarly named points such as Trip, Close, Block, and Alarm.

Which Network Packets Must Be Checked During GOOSE Testing?

Check Ethernet destination MAC address, VLAN tag, priority, APPID, GOOSE control block reference, dataset values, configuration revision, state number, sequence number, and retransmission timing. These fields prove whether the publisher sends the intended event and whether network delivery follows the approved design.

GOOSE is a Layer 2 multicast service, so IP addresses are not the primary test reference. A packet analyzer connected through a managed-switch mirror port should decode the frame without interrupting the operational path.

The packet fields that reveal the most commissioning errors are shown below.

For normal steady-state behavior, GOOSE retransmissions slow down after the initial event burst. When a data value changes, stNum should increment, while sqNum restarts and then increases through the retransmission pattern. If stNum does not change after a simulated protection pickup, investigate the publisher logic first—not the network.

How Can a Network Sniffer Validate Virtual Wiring Safely?

Use a managed switch mirror port or a passive network TAP to capture GOOSE traffic without inserting a laptop inline. Filter the capture by MAC address, APPID, VLAN, or GOOSE reference, then correlate packet timestamps with IED logic, binary inputs, and output contacts.

A mirror-port configuration is normally the least disruptive method for routine commissioning. Configure the switch to copy the relevant port or VLAN to the analyzer port. Avoid connecting an unmanaged switch between the relay and station LAN merely to obtain a capture; that can alter multicast behavior, introduce traffic flooding, or create an undocumented network path.

For high-value acceptance tests, capture three views at the same time:

• Publisher-side traffic, proving the IED transmitted the state.

• Subscriber-side traffic, proving the frame arrived at the destination network segment.

• Output evidence, proving the receiving logic acted correctly.

In one switchyard commissioning case, the publisher-side capture showed a 2 ms GOOSE event transmission, while the subscriber-side capture showed the same frame arriving 14 ms later during heavy engineering traffic. The root cause was not relay processing. A switch port had been assigned a lower-priority queue than the approved configuration.

Wrindu test solutions can be specified with Ethernet monitoring capability for teams that need to combine electrical test evidence with digital communication records. For B2B projects, Wrindu can also support custom test workflows, report formats, and equipment integration requirements for utilities, EPC contractors, relay-panel OEMs, and third-party laboratories.

What Should Packet Injection Prove in a GOOSE Test?

Packet injection should prove that a subscribing IED accepts valid approved GOOSE changes, rejects invalid or unauthorized variations, executes the correct logic, and returns safely when the condition clears. It must be performed in an isolated or properly blocked test condition to prevent unintended field operation.

A GOOSE packet generator should reproduce the approved communication identity, including VLAN, priority, APPID, multicast MAC address, control block reference, configuration revision, and dataset layout. Simply transmitting a frame with a familiar signal name is not sufficient.

Test these controlled cases:

• Valid trip assertion with the approved configuration revision.

• Valid reset or return-to-normal state.

• Incorrect confRev, verifying the subscriber alarm or rejection behavior.

• Incorrect dataset order, verifying no unsafe unintended action occurs.

• Missing retransmissions, confirming GOOSE supervision detects loss of communication.

• Replayed or stale state values, confirming logic does not create a false operation.

• High-rate background traffic, confirming the required GOOSE response remains stable.

Packet injection is an engineering test tool, not a shortcut around safety controls. Before any injected trip test, isolate trip circuits or use approved test blocks, confirm the breaker state, inform the control room, and obtain documented permission. For an energized station, never assume “test mode” in one IED protects every downstream path.

Why Do GOOSE Tests Fail Even When Packets Look Normal?

GOOSE tests often fail because communications are correct while application mapping, logic gating, dataset order, configuration revision, or output wiring is wrong. A valid packet only proves transmission; it does not prove that the receiving IED uses its value in the intended function.

The most expensive faults are usually small engineering mismatches. For example, a binary point may be present in the packet but mapped to the wrong input bit inside the subscriber. An interlock may be active during commissioning but absent in the final operating state. A signal can also be logically inverted: “breaker open” is interpreted as “breaker closed” because one team used normal-state naming while another used energized-state naming.

Based on years of handling factory and site test orders, these are the recurring failure modes:

• GOOSE publisher and subscriber use different dataset member positions.

• confRev changes after the subscriber configuration was loaded.

• VLAN membership is correct on the primary LAN but missing on the redundant path.

• Network switches suppress or filter multicast traffic unexpectedly.

• Test equipment injects only the changed bit but omits required quality or status elements.

• IED logic uses a timer, seal-in, or blocking condition that the test team did not document.

• Contact output proves correctly at the relay terminal, but panel marshalling wiring is incomplete.

A good virtual wiring report should therefore record not only “pass” or “fail,” but also the exact packet, timestamp, IED indication, logic state, and contact measurement associated with each test.

When Should Latency and Failover Be Measured?

Measure latency during site acceptance, after switch configuration changes, during redundancy tests, and whenever protection or breaker-failure logic depends on multi-IED messaging. Measure both normal-path timing and worst-case timing during network disturbance, not only a clean laboratory condition.

For many protection applications, the engineering target is measured in milliseconds rather than seconds. However, the acceptable value depends on the complete protection scheme: relay processing, network transport, subscriber logic, output contact operation, and breaker operating time all contribute to clearing performance.

A useful end-to-end measurement begins at the initiating event. For example:

1. Apply a simulated fault or binary input change to the publishing protection IED.

2. Timestamp the outgoing GOOSE state change.

3. Timestamp its arrival at the subscriber.

4. Measure the subscriber output contact transition.

5. Record the result against the approved scheme requirement.

Do not rely only on packet timestamp differences if the project needs true protection operating time. Packet capture proves transport delay, but it does not include every internal IED processing stage or the physical output contact response. A time-synchronized test instrument, binary I/O monitor, and network analyzer provide stronger evidence together.

How Can China Manufacturers Support Custom GOOSE Test Projects?

China manufacturers can support GOOSE testing projects by supplying configurable test equipment, custom I/O arrangements, project-specific cable sets, factory acceptance procedures, and OEM documentation aligned with the customer’s relay and network architecture. The best supplier works from the project signal matrix rather than offering a generic instrument alone.

For wholesale buyers and OEM panel builders, the commercial requirement is often as important as the protocol requirement. A factory should be able to define:

• Binary input and output quantity, voltage range, and wet/dry contact method.

• Ethernet port count, copper or fiber interface, and redundancy requirements.

• Test templates for breaker failure, busbar protection, intertripping, and transfer schemes.

• Custom front-panel language, branding, serial-number logic, and calibration labels.

• FAT documents, packing method, spare-part list, and after-sales response process.

Wrindu, officially RuiDu Mechanical and Electrical (Shanghai) Co., Ltd., supports electrical testing and diagnostic equipment projects with independent design and manufacturing capability. For customers sourcing from China, Wrindu can provide OEM and custom configurations that align test equipment with relay-panel production, commissioning workflows, and international delivery requirements.

What Are Wrindu Expert Views?

Wrindu Expert Views

“A GOOSE test is successful only when the engineering chain is closed: source logic, published dataset, Ethernet transport, subscriber validation, internal scheme logic, output contact, and reset state. In factory runs, we do not accept a green communication status as proof of virtual wiring. We require an observable state change at the intended endpoint and a documented result for the abnormal cases—lost message, changed configuration revision, incorrect VLAN, and redundant-path interruption. That discipline prevents a minor configuration error from becoming a major site delay.”

Can You Build a Repeatable GOOSE Test Procedure?

Yes. Build a repeatable procedure by separating static engineering checks, passive packet observation, controlled injection, functional output testing, and abnormal-condition verification. Reuse a formal test matrix, but review every signal’s logic context because identical names can perform different functions across bays.

A proven sequence is:

• Verify the approved SCL revision and IED configuration files.

• Confirm switch VLAN, priority, multicast, and mirror-port settings.

• Capture steady-state GOOSE messages from each publisher.

• Trigger each expected state change using a safe test input.

• Verify stNum, dataset values, and retransmission behavior.

• Confirm subscriber logic indication and physical output.

• Test reset, loss-of-message supervision, redundancy path, and negative cases.

• Export packet records and test results into the commissioning dossier.

The strongest projects treat this procedure as a controlled manufacturing process. For each panel or bay, use the same naming convention, acceptance thresholds, test connections, and report layout. This helps an OEM factory or electrical contractor scale from one pilot bay to dozens of repeatable deliveries without losing traceability.

What Are the Key Takeaways for GOOSE Virtual Wiring?

GOOSE virtual wiring must be proven as an end-to-end protection and control function, not merely as Ethernet traffic. Capture the approved packet, inject controlled changes, verify subscriber logic and physical outputs, measure timing, and document normal, failover, and failure behavior.

For reliable results, start with the current SCL baseline, monitor traffic through a mirror port or TAP, and use injection only under approved isolation and safety controls. Choose a supplier that understands both protection testing and industrial manufacturing requirements. Wrindu supports utilities, integrators, OEMs, and wholesale customers seeking dependable, custom-ready electrical testing solutions from China.

What is the difference between GOOSE monitoring and GOOSE injection?
Monitoring passively observes actual network traffic and proves what devices publish. Injection actively creates controlled GOOSE messages to test how subscribers react. A complete test program normally needs both methods.

Can Wireshark test GOOSE virtual wiring by itself?
Wireshark can decode and record GOOSE frames, timestamps, VLAN data, state numbers, and dataset values. It cannot alone prove that subscriber logic or a physical relay output operated correctly.

What is the most common GOOSE configuration error?
A frequent error is a mismatch between the publisher dataset and subscriber configuration, often caused by late engineering changes or an outdated configuration file. Configuration revision and dataset member order should always be checked.

Does a valid GOOSE packet guarantee a trip command will work?
No. The subscriber may reject the message, map it incorrectly, block it through logic, or fail to operate its output circuit. Verify the packet, internal logic state, and physical output contact.

Can a custom China factory supply equipment for GOOSE-related testing?
Yes. A capable manufacturer can provide configurable binary I/O, customized interfaces, OEM branding, tailored test templates, and documentation suited to specific protection-panel or commissioning workflows.