Another note on the use of SCL

Author: Christoph Brunner, it4power, Switzerland

As you know, Edition 1 of IEC 61850 had SSD, ICD, SCD and CID files. Edition 2 added IID and SED files, and there are discussions to add an ISD file. While these abbreviations are easily explained, it is impossible to have a common understanding of what the files behind are, and what they include.
After trying over the years to explain what these file types are intended for and desperately failing in doing that, I concluded that it does not really matter what you will call a file. There are too many variations of the engineering process that need to be supported. The important thing is, to know where you are in the process, what information you need in the file at that stage and which tool may configure what information.

When we look at the content of an SCL file, there are three major elements that are described:

  • The functional description of the project – in a substation the single line diagram and the functions with the associated logical nodes. This is the substation section
  • The communication network
  • The devices

For the devices, we describe its capabilities and unique identification, the data model that is supported configuration parameters for the functions, signal flow for implementing the functions and configuration of the communication. Currently out of scope for IEC 61850 is the configuration of IED internals: logic, binding to I/O’s and IED HMI.
Now – what tool shall configure what information? Basically, we can summarize that everything that is in the responsibility of the IED manufacturer shall be configured by the IED tool.
Anything which is related to the system design shall be configured by a system tool.

When we look at the process how to design a substation, we typically differentiate two main approaches: the bottom up approach, where we start from the IED tool defining the IEDs for the project and the top down approach, where the IEDs are created in the system tool using a template file.
To stay within the page length of this column, I will focus on the discussion of the IED related files.

For the top down approach, we start with a template file which as a minimum describes the IED capabilities and the data model supported by the IED. That file is usually called ICD and the IED in that file has the name TEMPLATE. In an initial step, it may be a good practice to customize the template file for the project by adjusting the data model for the functional requirements of the project (e.g. number of switches supported) in order to avoid having a data model with LNs that are not needed. Such a customization must be done by the IED tool; the resulting file would still be an ICD file.

With the bottom up approach, we start the process with the IED tool. In the IED tool we create all the IEDs required for the project. The resulting file has the same content as the template above - the only difference is that the IED has now a name other than TEMPLATE. Such a file, according to Edition 2 would be called IID and is imported by the system tool. To simplify file exchange, instead of transferring one file per IED between the IED tool and the system tool, one single file may be used that contains the specification of multiple IEDs. A name for such a file is not defined in the standard; it can be considered an incomplete SCD file; but the name does not matter; what is important, is that the system tool can extract the required information.
All files mentioned above may include dataset and control block elements. If the IED has limitations regarding the configurability, the system tool shall use these elements; otherwise it may throw them away.

During the design process, it may be required to do engineering cycles between the IED tool and the system tool. Iterations may be required to modify the data model based on the requirements. The standard foresees, that SCD files are transferred from the system tool to the IED tool and IID files back to the system tool. The key is, that the IED tool returns a file with an updated data model, that keeps all elements already included in datasets configured by the client and that does not change any configurations made for control blocks or for values of parameters.

More round trip engineering may be required related to the configuration of the signal flow (ExtRef) regarding IED internal addresses and diagnostic support (LGOS). Basically - during the design steps, the IED related configuration in the SCL file is gradually increasing until completed. During that, it is important that the tools respect the responsibilities of each tool.
Once the configuration is done, the IED tool typically imports the SCD file and extracts the relevant information or an individual IED to configure it. That information contains the full description of the IED to configure, but includes communication parameters and information from other IEDs that publish messages to be received by that IED.  

Christoph Brunner is the President of his own independent consulting company it4power LLC based in Switzerland. He has over 25 years of experience with knowledge across several areas within the Utility Industry and of technologies from the Automation Industry. He has worked as a project manager at ABB Switzerland Ltd in the area of Power Technology Products in Zurich / Switzerland where he was responsible for the process close communication architecture of the automation system. He is Convener of WG 10 of the IEC TC57 and is a member of WG 17, 18 and 19 of IEC TC57. He is senior member of IEEE-PES and IEEE-SA. He is an IEEE Fellow and he is active in several working groups of the IEEE-PSRC and a member of the PSRC main committee and the subcommittee H. He is international advisor to the board of the UCA international users group. 


Relion advanced protection & control.
BeijingSifang June 2016