IEC 61850 SCL Files: ICD, CID, SCD and SSD

Back to Blog

One Language, Several File Roles

SCL is a single XML schema, but the standard defines several file types that use it at different points in the engineering workflow. The differences are about scope and completeness, not syntax. An ICD (IED Capability Description) is what a vendor ships: it says what one device type can do - its logical nodes, data, and possible datasets - without project-specific addressing. An SSD (System Specification Description) goes the other way: it captures the substation single-line diagram and the functions required, with no IEDs assigned yet, so it is the specification the design starts from.

The project-specific files fill in the middle. An IID (Instantiated IED Description) is a single IED configured for this project. The SCD (Substation Configuration Description) is the big one: it contains every IED, the full communications section with all GOOSE and report subscriptions, and the substation section, so it is the master engineering artifact for the whole station. A CID (Configured IED Description) is the slice of the SCD that gets downloaded into one specific device.

How the Files Flow Through Engineering

The normal flow runs specification to devices. You begin from an SSD that states what the substation must do. Vendors provide ICDs for their candidate IEDs. A system configuration tool combines the SSD requirements with the chosen ICDs, wires up the data flows (which IED publishes what, who subscribes), and produces the SCD - the complete station description. From the SCD, an IED configuration tool extracts a CID for each device and loads it.

Getting the file type right at each handoff prevents rework. A vendor cannot commission from an SSD; a system tool cannot build data flows from CIDs alone; a device cannot be programmed from an SCD directly. When you plan reporting and subscriptions, you are editing the communications section of the SCD, which is why the SCD is also where you verify that GOOSE publishers and subscribers actually line up. SCL is the concrete configuration layer sitting under the model described in the IEC 61850 series structure.

The File Family at a Glance

When you need the whole family in one view, the handoff map looks like this:

File	Scope	Produced by	Consumed by
ICD	Device type capabilities, no project addressing	Device vendor	System configuration tool
IID	One IED instantiated for a project	IED configuration tool	System configuration tool
SSD	Single line and required functions, no IEDs assigned	Specification stage	System configuration tool
SCD	Entire substation: all IEDs plus communications	System configuration tool	IED tools, test sets, documentation
CID	Configuration for one physical device	IED configuration tool	The IED itself

Read the table by rows when someone hands you a file and by columns when you need to produce one. If a file arrives with no communications addresses, it is capability or specification material, not something a device can run; if it contains exactly one IED with full addressing, it is a CID or an IID depending on which direction it is travelling in the workflow. The extension on the filename is a claim, not a guarantee - tools and people mislabel these files constantly, so when a handoff misbehaves, open the XML and check whether the content matches what the extension promises before blaming the tool on either side.

Top-Down on Paper, Bottom-Up in Practice

The standard describes a tidy top-down flow from SSD to SCD to CID, but many real projects run bottom-up: each IED gets configured in its own vendor tool, and the integrator assembles the station-level picture late, partially, or never. That approach works until the first data-flow change, because without a current SCD there is no single description of who publishes what and who subscribes to it - every later modification starts with reverse-engineering the station from device exports and drawings. Bottom-up delivery is sometimes unavoidable on retrofit work, but it should end with an assembled SCD as a deliverable, not with a folder of vendor project files.

The durable habit is treating the SCD as the master artifact and versioning it like source code. Every approved change lands in the SCD first; CIDs are re-exported from it, version-stamped, and diffed before anything is downloaded to a device. Drift between the SCD and what the devices actually run is the substation equivalent of configuration drift on servers, and it surfaces at the worst possible moments - during a fault investigation or a protection test, when the documentation says one thing and the relay does another.

Pitfalls When Exchanging SCL Between Tools

SCL is standardized XML, but tool interoperability is imperfect in practice. Schema version mismatches between Edition 1 and Edition 2 tools are the classic failure: a file that validates in one tool is rejected or silently trimmed by another. Vendor private sections are the second trap - tools may drop another vendor's private elements on import and re-export, so the safe habit is to round-trip a file through the receiving tool early and diff the result against the original before the project depends on it.

The other error family is broken references. A dataset referenced by a report control block or a GOOSE control block names its members by object reference, and a renamed or deleted logical node can leave a file that still validates against the schema yet fails on the device, or worse, fails only at runtime when a subscriber finds nothing behind the name. Validate cross-references as well as schema, and prove each subscription end to end during commissioning rather than trusting a clean file import.

Frequently Asked Questions