Why do top-down engineering?

Author: Christoph Brunner, it4power, Switzerland

Part 6 of IEC 61850 describes the design and engineering process using the substation configuration language (SCL.) The process includes a system configuration tool (SCT, product independent) and IED configuration tools (ICT.)  SCL files are exchanged between tools.  Also, not explicitly mentioned in IEC 61850-6, we typically differentiate between a top-down approach and a bottom-up approach. In the past, most of the time, a bottom up engineering approach was used, which means, the IEDs are created in the ICT and imported in the SCT (as for example IID files) to do system level configuration like GOOSE messaging and reporting. Often, the flexibility of what the ICTs accepted as configuration changes regarding GOOSE and reporting was limited, so the use of a SCT was considered more of an additional step in the engineering process, rather than being helpful.

However, with IEC 61850 getting more mature, ICTs provide more engineering flexibility, and the definitions in the standard became clearer and more restrictive regarding options. Experienced system integrators have always been aware of the benefits the use of a SCT would provide compared to an ICT based engineering, and many of them consider that now is the time to push top down engineering. With top down engineering, a project is created in the SCT by first creating the specification and then, for the realization, import template files (ICD) for the various IEDs used.
Once the system is configured with the SCT (which means among others to create IED instances, configure GOOSE messaging, reporting or communication parameters,) the SCD file which is the result of that step is loaded into the ICT.  The ICT now extracts all the relevant information to configure the IEDs.
To be successful with that approach and to profit from the benefits, it is important that the ICT supports it. This requires the ICT supports to create the IED instances used for a project from the SCD file.  It is also recommended that at least ICTs for flexible IEDs, support the configuration of data sets and control blocks through the SCT - other than having predefined fixed ones.

Now - why would you want to do this?  From the perspective of an integrator, that is not linked to a product vendor - like a utility, or an independent integrator - this allows you to do most of the work in one tool that is product independent. It also allows you to do an electronic specification of your typical bays and configurations as well as your projects in a machine processable way and product independent - at least as much as it relates to IEC 61850 aspects.
An interesting question is - what can be included in this product independent specification? Looking at the promises for IEC 61850, many utilities are looking into the possibility of doing a complete product independent design - which means, they want to specify the interactions to implement their protection schemes before they decide to use a vendor A or vendor B product.
Such an approach allows the maximum of reusability of a design for various projects that may use different products.

The standard is already supporting that today, using what we call virtual IEDs. That means, to create ICD files that reflect the data model needed for the application and to do the system design using those virtual IEDs. When realizing a project with specific products, the only engineering steps that need to be done are to map the Logical Nodes and data from those virtual IEDs on the real IEDs. As a side effect, an SCD file with those virtual IEDs and the related GOOSE messages can be created and used with simulation tools to simulate the design even before it is implemented in real devices.

But the technology used allows us to go a step further. As part of a European Research project (OSMOSE) based on input from ENTSO-E (the European organization of TSOs,) we are currently working to extend SCL to allow signal flow specification independent of virtual devices.  Also, we are working in the WG10 of IEC TC57 to improve the specification of functions - this will allow us to better understand the semantic of a particular logical node instance and will be documented in IEC 61850-6-100. Finally, we add the capability to export from the system specification as well as the IED specification in a machine processable format. And here we plan to go way beyond the pure IEC 61850 aspects - we are looking into extending SCL to provide a complete digital representation of all the requirements - EMC, physical I/Os etc. Basically, defining a digital twin of the IED.
I recently observed an increasing number of utilities and integrators to do a top down engineering to make maximal use of the gain in engineering efficiency offered by the standard. The specifications available today with amendment 1 of Edition 2 of the standard support that. And many forward-looking vendors support these new features. 


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 is active in several working groups of the IEEE-PSRC and a member of the PSRC main committee and the subcommittee H. He is advisor to the board of the UCA international users group. 

Power. Flexible. Easergy.
Protecting your electrical assets? today and tomorrow