Quality Assurance requirements and experiences for GOOSE/SV configuration

The paper describes our experiences in applying quality assurance principles during the off-line SCL engineering phase independent of the engineering tool or Excel files used. These principles include requirements for inspection, visualisation and detailed analysis of the configuration of the GOOSE and SV communication all directly from the SCL files. The results of these processes are presented in regards to optimised data flow, identification of unpublished or unsubscribed GOOSE/SV, restriction of use of generic Logical Nodes and generic signal names ensuring better overall performance and reliability.

May 5, 2020, 8:59 p.m. | 5658 Программное обеспечение (SS)

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.

Latest blog posts

Disrespectful Sampled Values subscriber behaviour
Disrespectful Sampled Values subscriber behaviour

Teaser: Some IEDs require that SV (or maybe GOOSE) messages on ingress port of the IED have proper VLAN tag (as configured in the subscription), thus resulting in failure to receive the untagged messages (or messages with another VLAN ID tag). Such behaviour of an IED is wrong but sometimes you can meet this. Read the full article to dig into the details.

When GOOSE can't fly!
When GOOSE can't fly!

Everyone who ever dealt with the commissioning of IEC 61850 based systems had situations when there were problems in establishing successful GOOSE communications between IEDs. The reasons for that are always different. There may be a fault of the commissioning engineer, a fault of the vendor or it may be a fault of both parties at the same time. We have faced such situation recently and this was the case when one could blame... decide yourself who is to blame in this situation, having read this note about nuances in configuring GOOSE-communications between IEDs of two different vendors.

Transmission of data structures in a GOOSE message
Transmission of data structures in a GOOSE message

GOOSE-messaging has been covered a lot in many technical papers and to add anything valuable to the subject is rather difficult. But we will try. And functional constrained data will help us with that.