A breaker-fail backup trip from a bay IED does not reach the busbar protection. Following the ExtRef back to the publisher's control block and data set finds two configuration errors.
| Publisher | Bay IED Q02_BCU, logical device CTRL, GOOSE control block gcbBF using data set dsBF |
| Data set dsBF | RBRF1.OpEx.general (ST) and RBRF1.OpEx.q (ST) |
| Subscriber | BB_PROT, input mapped by an ExtRef to Q02_BCU / CTRL / RBRF1.OpIn.general, srcCBName gcbBFail |
| Symptom | A breaker-fail backup trip from bay Q02 never trips the busbar zone during testing |
The ExtRef in BB_PROT names the source IED, logical device, logical node, data object and the control block it expects the signal in. Validation checks each part against the publisher.
The control block in the publisher is called gcbBF. The subscriber was configured from an earlier revision of the publisher's ICD file, where it had a different name.
Point the ExtRef's srcCBName at gcbBF and validate again.
The data set carries RBRF1.OpEx, the breaker-fail backup trip to the surrounding breakers. The ExtRef asks for RBRF1.OpIn, the internal re-trip of the bay's own breaker, which is a different data object and is not published at all.
| Item | Configured | Required |
|---|---|---|
| Control block | gcbBFail | gcbBF |
| Data object in ExtRef | RBRF1.OpIn.general | RBRF1.OpEx.general (or add the required signal to dsBF) |
Decide with the protection designer which signal the busbar scheme needs. If it really needs a signal that is not in the data set, add it to dsBF on the publisher side, which changes the data set and so the control block's configuration revision.
Here the busbar scheme should use OpEx, so the ExtRef is corrected to RBRF1.OpEx.general. Validation now reports no ExtRef errors or warnings. If the data set had been changed instead, the publisher's confRev increases and the subscriber must be reloaded so both sides agree.
Export the updated CID for BB_PROT, load it with the manufacturer's tool, and repeat the breaker-fail backup-trip test, checking the GOOSE message on the network and the input status in the busbar IED.
| Check | Requirement | Actual | Status |
|---|---|---|---|
| ExtRef source control block exists | srcCBName matches a GSEControl in the source IED | Was gcbBFail (not found); now gcbBF | ✓ PASS |
| Subscribed signal is in the data set | ExtRef points to a data set member | Was RBRF1.OpIn (not published); now RBRF1.OpEx.general | ✓ PASS |
| Validation clean | No ExtRef errors or warnings | None reported | ✓ PASS |
Key insight: A GOOSE subscription only works when four things agree: the source IED, the control block name, the data set member and the configuration revision. Checking the ExtRef against all of them in the SCD finds most "signal not arriving" faults before anyone goes to site.
Every input in this example is editable in the live calculator — no signup needed.
Open IEC 61850 SCL Editor (SCL Studio) calculator →The subscriber decodes GOOSE values by their position in the data set. If members are added or reordered, the publisher's confRev changes and a subscriber still configured for the old revision should reject the message.
No. It shows the configuration is consistent. The manufacturer's tools, the loaded CID files and a functional test on the network confirm that the IEDs actually behave as configured.
It is good practice to include and check the quality (q) of protection signals so the subscriber can treat invalid or test-mode data correctly.