It is said that the correct way to describe IEC 61850 is that it “is no mere protocol, but rather an engineering process to configure IEDs to communicate”. The Standard defines three engineering tools and six System Configuration Language (SCL) file types used in the off-line engineering process in IEC 61850-6. From the practical point of view whilst humans can “read” SCL files, it is impossible to gain a complete understanding of how the system works and which signals are being created and used by the various IEDs. This is due to the complexity of the syntax of the language and significant size of these files with hundreds of thousands lines. Meanwhile, SCL files describe communications between IEDs and understanding them is important at different lifecycle stages of the electric power facility.

Several IED Configuration and System Configuration Tools provide a kind of visualisation for SCL files either in tabular, or in primitive graphical form without some level of detail. These formats may be suitable for creating configurations, but it Is not easy to identify errors in the project. Errors need to be identified at the initial “desktop” engineering configuration, at FAT/SAT/Commissioning phases (missing/wrong virtual connections), to those which can lead to performance degradation of protection and control schemes.

The key objective of IEC 61850-6 SCL files is to configure IEDs to communicate in multi vendor projects. Vendor-specific are obviously needed as the IED Configurator Tool defined in IEC 61850-6, but many do not behave well for multi-vendor projects. Moreover in most cases those tools are mainly designed managing the ICD and CID files, which generally makes them hard-to-use for visualisation, analysis and validation purposes of the complete multi-vendor SCD. In any case, quality assurance principles would suggest that we should not be using the same tool as we used to create the configurations as the tool for validating the configurations in case the tool itself is creating and hiding the errors.

GOOSE and Sampled Value configuration is usually prescribed or “explained” by the ubiquitous Excel Publisher/Subscriber matrix, often generated by humans. As an engineering process this offers very little scope for visualising and validating precisely how the communications are configured in the SCL files leaving the discovery of problems to the FAT/SAT/Commissioning phases requiring appropriate specialist tools. As a result, it is often a “trial and error” process when loading the SCL files to the individual IEDs. This is in direct contrast/conflict to the well-used approval processes for all the drawings and configuration files in wire-based schemes prior to loading in the IEDs.

Use of SCL for system design

It is known that the IEC 61850 standard unlike many other communication standards defines the System Configuration Language (SCL) that can be used to describe IED configurations and communication systems according to IEC 61850-5 and IEC 61850-7-x. It allows the formal description of the relations between the utility automation system and the process (substation, switch yard) [1].

SCL usage

There are two main purposes SCL is used for in nowadays projects:

• Description of IED data model and capabilities,
• Description of IED communication configurations.

There are also three more points for SCL that are not widely used so far in projects but are worth mentioning as further applications:

• Description of the process (i.e. substation, or switchyard with its primary equipment) and functions mapping,
• Description of protection settings (that in fact is a part of the IED data model description, but being optional, is not widely used to date),
• Description of programmable logic, which was not defined by [1], but was later described by a technical report.

Mentioned usages of SCL as can be seen from above actually cover all use-cases for IED configurations. I.e. SCL file in a meantime can be used of the only configuration file for the IED, which might be very convenient from the point of view of maintainability and usability.

Human-readable SCL

The SCL is based on Extensible Markup Language (XML). The XML itself is a markup language that can be used for description of almost any kind of structured information. It defines a set of rules for encoding text-based documents in a format that is machine-readable specifically to eliminate human interpretation when passing information from one tool to the next. XML as text also remains human readable to some extent when needing to inspect certain sections of files.

IEC 61850-6 SCL is a subset of “all-purpose” XML which restricts it to a set of certain structures and syntax suited to all aspects of power utility automation systems both within the substation and throughout the grid for protection, SCADA, control, condition monitoring and metering. This so-called “restriction” is provided by SCL Schema defined by [1], providing certain rules for the structure of SCL documents.

In practical applications SCL files, describing the configuration of real-world substation could exceed millions lines of code. Although being human-readable, the sheer size and coding makes them extremely hard for humans to be interpret, understand and analyze what the system is intended to do, i.e. it is very difficult to trace a signal sent from one IED to another as is possible by “line chasing” on wire-based system drawings.

Human-written Excel Matrices for GOOSE-communications

One of the most impressive features of IEC 61850 is undoubtedly GOOSE message protocol defined in IEC 61850-8-1 enabling protection and automations systems with real-time communication capabilities. GOOSE protocol, being Layer-2 multicast protocol as defined by [2] and [3] uses “Publisher-Subscriber” association model, where one message published on the network can be subscribed by any number of IEDs without nominating them in the publishing IED configuration.

IEC 61850 defines somewhat strict rules for description of GOOSE publishing. SCL file describes dataset published with the GOOSE-message as well as GOOSE Control Block configuration and GOOSE Communication Parameters. However GOOSE-subscription cannot be seen from SCL-file in a glance — in a standard way GOOSE-subscriptions are defined in “Inputs” sections of Logical Nodes (or in certain cas ing and GOOSE-subscriptions.

In order to overcome mentioned issue many engineers ended up with creation of Excel matrices for GOOSE publishing and subscriptions. In rare cases such kind of matrices were created automatically based on SCL-file, where in most cases — manually.

The Excel table for GOOSE (or SV) publishing and subscription still have major drawbacks:

• If created manually this table might contain errors;
• Not flexible enough to give a fast overview of GOOSE(SV)-message and it’s contents;
• Might be hard-to-maintain and analyse in case of many IEDs in the project;
• Have no capability for further automation of analysis.

With potentially hundreds of IEDs on each axis it is not all that easy to verify the configuration. In any case, it is wise to use a different visualisation tool of the configuration than the tool used to create the configuration as the same tool may inherently hide the errors – if they were able to be created by using the spreadsheet, they may also be missed when looking at the spreadsheet.

SCL Tools Overview

IEC 61850 standard describes the engineering process for an automation systems with the use of set of tools [4]:

• system specification tool (SST): allows specifying the system and device requirements regarding the needed system functional and process capabilities;
• system configuration (system design) tool (SCT): allows selection of needed IEDs based on a system (requirements) specification, and defines the communication connections between the IEDs of the system and the logical relations between IED functionality and the primary equipment. Often the system configuration tool includes a system specification tool;
• IED configuration (parameterization) tool (ICT): allows making the detailed parameterization of an IED based on a system design and requirement specification beforehand and a system description delivered by the system configuration tool after the system configuration process.

In order to enable interoperable exchange of engineering data between IED parameterization tools of different manufacturers and the system configuration tool, as well as between different system configuration tools handling different system parts as separate projects, [4] defines the use of SCL syntax for configuration files transferred between the mentioned tools. This continues through all activities of the lifecycle of the system as discussed in [5] and [6].

System Specification tool as defined by the standard is referred to when specification of system functionality and process capabilities is required and usually never goes deeper into communication dataflow and protocol configurations. Whereas System Configuration as well as IED configuration tools are both used for system (or IED) configuration and export of final configuration including GOOSE- and SV-communications configuration.

In most cases, however, the intended purpose of those tools is configuration, but not visualizations and configuration analysis. So in case of use of different tools the user could either suffer from lack of tool interoperability (especially in multivendor-projects) or application-specific analysis. There are many horror stories of vendor-specific ICT, even SCT, not accepting/understanding the SCL files produced by a different vendor’s tool, in some cases even rejecting the changes made by the previous tool and reverting the contents to what the second tool “thinks” the content should be according to its own capabilities!

Table 1 summarizes capabilities of SCT and ICT in different areas based on the practical experience and overview of the authors with modern tools, where “-“ means the capability is unavailable, “+” the capability is available, “+/-“ means that the capability could either be available or unavailable dependent on the tool, or could be poorly implemented by the tool user or overviewed.