Jul 19, 2026Case Studies
IEC 61850 SAS Commissioning Failure
Learn the lesson from the IEC 61850 SAS commissioning failure case. In the following projects, those experiences will be much more helpful.
IEC 61850 SAS Commissioning Failure Caused by the Wrong ICD File
The most dangerous fault in a substation automation system[¹] is not always inside the relay. Sometimes it starts earlier, inside a configuration file that everybody assumes is correct. This case documents a 132/33 kV brownfield-style SAS commissioning issue where protection relays kept restarting and some circuit breakers tripped without clear reason until the real cause was traced back to the wrong IEC 61850[²] configuration using incorrect ICD (IED Capability Description) files[³] during system engineering and commissioning.
Project Snapshot
Item | Description |
|---|---|
Industry | Power Transmission / Substation Automation |
Application | SAS system for a 132/33 kV substation |
Project Type | Commissioning troubleshooting and IEC 61850 configuration recovery |
Location | Gulf region |
Products | IEC 61850 protection relays, SAS system, gateway to control center |
Services | Site troubleshooting, configuration review, relay file verification, functional testing |
Communication Protocols | IEC 61850 inside the station, IEC 60870-5-104 to the main control center |
Result | Wrong ICD files identified, configuration rebuilt, relay restart issue solved, and normal commissioning tests resumed |
Project Overview
This project was a substation automation system commissioning job for a 132/33 kV station in the Gulf region. The station devices were based on IEC 61850, and the complete SAS system was connected to a main control center through IEC 60870-5-104.
When I arrived, the project was already under pressure. The previous commissioning work had not been fully handed over, and several site issues were still open. Some circuit breakers were tripping without a clear reason, and some protection relays were stuck in repeated restart behavior.
That is not the kind of problem anyone wants to hear about at the airport.
The security engineer who picked me up looked worried before we even reached the car. He told me there was a serious issue at the site and that the customer expected a quick solution. I spent most of that night thinking through possible causes before I even saw the panels.
The next morning, after safety induction, I went directly to the SAS and protection relay area. The pressure was clear. People wanted answers, but the system was not giving obvious clues. At first, the configuration files on the engineering workstation appeared to match what was inside the relays.
But the real problem was not in what the file looked like after downloading.
The problem was in the file used to build the configuration from the beginning.
Customer Challenge
From the customer’s perspective, the situation was serious because the station was already in the commissioning stage. At this point, the expectation was not discovery. The expectation was completion.
The customer had a 132/33 kV SAS system that should have been ready for normal testing, but instead the site team was dealing with unstable relay behavior and unexpected circuit breaker trips. That immediately created concern about protection reliability, automation stability, and commissioning quality.
The customer’s concerns were practical:
- Some circuit breakers appeared to trip without a clear cause.
- Some protection relays were continuously restarting.
- The IEC 61850 configuration could not be trusted.
- Previous commissioning knowledge had not been fully handed over.
- The project team was under pressure to recover quickly.
- The control center interface still depended on a stable station-level SAS.
- The customer needed proof, not guessing.
This is the painful part of SAS commissioning. When a relay restarts, people often suspect firmware, hardware, power supply, communication storms, network configuration, or relay setting corruption. When breakers trip unexpectedly, the pressure becomes even higher because nobody wants to continue testing a system that may operate equipment incorrectly.
The site atmosphere was tense because the problem touched both protection relay[⁴] and control confidence. A relay that restarts repeatedly cannot be accepted. A breaker that trips without a clearly understood cause cannot be explained away.
If the root cause had not been found, the team could have wasted days replacing devices, reloading files, changing network settings, or blaming the wrong part of the system. Worse, the customer's confidence in the entire SAS could have been damaged.
The real challenge was to stop reacting to symptoms and go back to the foundation of the IEC 61850 engineering process[⁵] and verify the system against internationally recognized Smart Grid standards[⁶] before making further changes.
Engineering Review
The engineering review started with the basic troubleshooting rule I always trust: question the foundation before chasing complex theories.
At first, the visible evidence was confusing. The configuration files seemed to match the downloaded files inside the protection relays. The relay settings looked familiar. The IEC 61850 structure did not immediately show a clear mismatch. On the surface, everything appeared close enough to pass a quick review.
But “close enough” is dangerous in IEC 61850 projects.
In IEC 61850 engineering, the ICD file is not just a document. It is the device capability description that tells the engineering tool what the relay supports, what logical nodes exist, what data objects are available, and how the device can participate in the station configuration.
If the wrong ICD file is used, the whole configuration is built on a false device model.
That became the key review point.
Instead of starting with advanced packet analysis or replacing devices, I reviewed the configuration path from the beginning:
Review Item | Engineering Question | Risk if Ignored |
|---|---|---|
ICD file source | Does the ICD file match the exact relay type and version? | Entire configuration built on wrong device model |
Relay type | Does the relay hardware match the engineering file used? | Wrong logical nodes or unsupported data objects |
IEC 61850 version | Is the configuration built with the correct standard/version compatibility? | Communication or download instability |
SCD/CID files | Were final files generated from the correct base files? | Wrong configuration downloaded to relays |
Warning messages | Were engineering tool warnings reviewed or bypassed? | Known mismatch ignored before download |
Relay restart behavior | Is a restart linked to a configuration mismatch? | Hardware suspected unnecessarily |
Breaker trip logic | Are GOOSE, interlocks, and outputs mapped correctly? | Unwanted operation risk |
Handover status | Are previous configuration decisions documented? | Slow troubleshooting and repeated mistakes |
Functional testing | Can one corrected relay be tested before mass changes? | Wider risk during recovery |
Documentation control | Are corrected files archived and reviewed? | The same issue repeated later |
The turning detail came when I noticed that the ICD file used in the project did not match the actual protection relay type installed in the station.
That one detail changed the whole picture.
It became clear that the configuration had likely been built using ICD files from an older project. The engineering tool had given a warning message during file download, but the warning had been bypassed. Once that happened, every configuration file generated from that wrong source became questionable.
This explains why the issue felt strange. The problem was not a simple wrong setting. It was a wrong foundation.
A relay can accept a file, but that does not mean the file is correct for the device. A warning message during download is not decoration. It is the engineering tool telling you that something deserves attention before the system is trusted.
Critical Engineering Decision
The turning point of the project was the decision to stop treating the relay behavior as a device fault and rebuild the configuration from the correct ICD file.
Before that moment, there were many possible explanations. The relay restart could have been firmware-related. It could have been an auxiliary power issue. It could have been network traffic. It could have been a corrupted download. The breaker trips could have been caused by GOOSE communication[⁷], interlock logic, output assignment, or protection setting errors.
All of those possibilities were reasonable.
But once the ICD (IED Capability Description) file[⁸] mismatch was found, the question changed. It was no longer, “Why is this relay behaving strangely?” It became, “Can we trust any configuration built from the wrong device file?” Reliable engineering depends on applying internationally recognized IEC standards[⁹] throughout the configuration and validation process.
The answer was no.
There were two possible approaches:
- The first approach was to patch the existing files. This may have looked faster under pressure. The team could adjust individual settings, try to suppress warnings, reload files, and continue testing. But that would only repair symptoms while leaving the foundation questionable.
- The second approach was to rebuild the configuration from scratch using the correct ICD files for the actual relay types installed in the station. This required more work, but it gave the project a clean engineering base.
We selected the No. 2 approach.
This decision truly changed the result. Instead of trying to rescue a bad configuration, we removed the bad foundation.
The first corrected configuration was tested on one affected device. That was important. In a pressured site situation, it is tempting to update everything at once. But if the new file has an error, the whole station becomes unstable again. Testing one device first gave the team proof before wider correction.
After the corrected file worked on the first relay, the office team reviewed and rebuilt the remaining files. Once the correct files were downloaded to the devices, the restart issue was resolved, the unexplained behavior stopped, and normal commissioning tests could continue.
The lesson was clear: if the base file is wrong, every file generated from it carries the same risk.
Solution Delivered
The solution was not hardware replacement. It was engineering recovery through correct IEC 61850 configuration control.
The first step was gathering site information. I spoke with the team to understand when the problem started, which devices were affected, and what actions had been taken before the issue appeared. This helped avoid random troubleshooting.
The second step was comparing the configuration files with the files inside the protection relays. At first, there was no obvious difference. That could have misled the team into thinking the issue was deeper in the network or relay hardware.
The third step was reviewing the configuration source files, especially the ICD files used to build the SAS configuration. This is where the mismatch was found. The ICD file did not match the actual device type installed in the station.
The fourth step was rebuilding the configuration using the correct ICD file. The corrected configuration was not immediately applied everywhere. It was first tested on one affected device so the team could confirm that the relay accepted the configuration and operated normally.
After the first test succeeded, the corrected configuration approach was shared with the office team. They reviewed all affected files, rebuilt them with the correct device files, and sent the updated configuration package back to the site.
The final step was downloading the corrected files to the protection relays and repeating the required functional tests.
After the correct configuration files were applied, the relay restart issue was resolved. The affected devices became stable, and the commissioning team was able to resume normal SAS testing.
This was a good reminder that configuration engineering is part of protection reliability. In IEC 61850 systems, one wrong source file can create problems that look like hardware failure, network instability, or unexplained logic behavior.
Before Shipment Verification
For this case, the important verification was not only before shipment. It should have happened before file download, before relay configuration acceptance, and before site commissioning pressure became critical.
The following checks became essential:
Verification Activity | Why It Mattered |
|---|---|
Relay type verification | The confirmed actual relay model matched engineering files |
ICD file verification | Ensured the device capability file matched the installed relay |
IEC 61850 version review | Confirmed compatibility between tools, files, and devices |
Warning message review | Prevented known mismatch warnings from being ignored |
SCD/CID file generation check | Verified final files were built from correct sources |
Single-device test | Confirmed corrected configuration before applying widely |
Relay restart observation | Verified stability after corrected download |
GOOSE and signal mapping check | Confirmed breaker-related signals were mapped correctly |
Functional test | Proved normal operation after configuration correction |
Documentation review | Captured corrected files and lessons for future work |
Handover review | Reduced dependence on incomplete verbal project history |
Backup archive | Preserved correct configuration files for future maintenance |
The most important item was ICD file verification. Before any IEC 61850 configuration is downloaded, the engineer should confirm that the ICD file matches the exact device type, firmware or model family where applicable, and project requirement.
The second most important item was warning message discipline. A warning message should never be bypassed just because the tool allows it. The tool may still complete the download, but the warning tells the engineer that the configuration deserves review.
The third important item was single-device testing. When recovering a project under pressure, updating all relays at once may feel faster, but it increases risk. Testing one affected device first gives evidence. Once the device behaves correctly, the team can proceed with more confidence.
This verification process matters because IEC 61850 configuration problems can hide behind symptoms that look unrelated. A relay restart may not immediately point to the ICD file. A breaker trip may not immediately point to the device model definition. That is why the basics must be checked first.
Project Results
The issue was resolved after rebuilding and downloading the correct configuration files.
The result was practical and measurable:
- 1 SAS system under commissioning for a 132/33 kV station was recovered from a critical configuration issue.
- 2 communication layers were involved: IEC 61850 inside the station and IEC 60870-5-104 to the main control center.
- Multiple affected protection relays were stabilized after correcting the configuration source.
- 1 root cause was identified: the wrong ICD file had been used to build the IEC 61850 configuration.
- 1 corrected configuration was first tested on a single affected relay before wider application.
- Normal commissioning tests resumed after the corrected files were applied.
The strongest result was that the team avoided unnecessary hardware replacement and avoided chasing the wrong fault path. The protection relays were not the real problem. The foundation of the configuration was there.
Once the correct ICD files were used, the relay restart problem disappeared, and the SAS commissioning process returned to normal testing.
This result also helped restore confidence at the site. Before the root cause was found, the problem felt unpredictable. After the ICD mismatch was identified, the issue became understandable and correctable. That change is important during commissioning because people trust systems they can explain.
The project continued successfully because the team went back to the basics instead of getting trapped in complex theories too early.
Engineering Notes from Natalie
This case is a strong reminder that warning messages deserve respect.
I understand why engineers sometimes bypass them. The site is under pressure. The customer is waiting. The file appears to download. The tool gives a choice to continue. It is easy to think, “We will check it later.”
But in IEC 61850 work, a warning during configuration download can be the difference between a stable station and days of confusion.
What stayed with me in this project was the feeling before the root cause was found. People were looking at the relays, the breakers, the network, and the commissioning schedule. Everyone wanted the problem solved quickly, but the system was not explaining itself clearly.
The solution came only when the basics were questioned again. Which file was used? Does it match the actual relay? Was the warning ignored? Was the configuration built on the right device model?
That is the discipline I try to keep. Before looking for a complicated failure, make sure the foundation is true.
Lessons Learned
1. Never ignore an IEC 61850 warning message
If the engineering tool warns that a file does not match the device, stop and review it. Continuing may create a configuration that downloads but does not operate reliably.
2. Verify the ICD file before building the configuration
The ICD file defines the device capability model. If it does not match the installed relay, the entire SCD/CID configuration may be wrong.
3. Do not assume previous work is correct
Incomplete handover increases risk. Every inherited file, setting, and configuration source should be verified before commissioning decisions are made.
4. Start troubleshooting from the basics
Relay restart and unexplained trips may look like complex failures, but the cause can still be a basic configuration mismatch.
5. Test one corrected device before updating all relays
When recovering a site issue, prove the correction on one affected device first. This reduces risk and gives the team evidence before wider deployment.
6. Wrong source files produce wrong results
Any configuration built on the wrong ICD file will carry that error forward. Correcting output files is not enough if the source file is wrong.
Key Takeaways
✔ In IEC 61850 commissioning, the ICD file is part of the protection system’s reliability.
✔ A warning message should be investigated before any configuration is accepted.
✔ When relays behave strangely, verify the configuration foundation before blaming hardware.
Need Similar Support?
If you are preparing an IEC 61850 SAS project, a protection relay retrofit, a substation commissioning recovery, or a control center integration, send us the following:
✓ Substation SLD
✓ Relay List
✓ ICD/SCD/CID Files
✓ IEC 61850 Architecture
✓ Control Center Protocol Requirement
We can review the configuration foundation before commissioning, including device file matching, signal mapping, GOOSE logic, relay communication, IEC 104 gateway points, warning messages, and the checks that prevent site recovery work under pressure.
Related Articles: