Why do top-down engineering?

Author: Christoph Brunner, it4power, Switzerland

When you read the title of the column, you probably recognize it. You are right - my last column already had that title. The reason I repeat it? Quite simple - I have something to add based on recent experience; I have more to say and the space in the last column was not enough.
I mentioned a few arguments for top down engineering and vendor independent design in my last column. Another requirement I always hear in discussions with utilities is, to achieve besides a vendor independent design, as well a vendor independent naming.
Users want to have signal names that are independent from the products. But what does that mean? As IEC 61850 is using names as communication addresses, users would like to see their product independent names in the communication address. In IEC 61850, the name used for the communication address is basically created out of the logical device name, the logical node prefix and the logical node class name like XCBR. With Edition 2, we added the optional capability that the user can configure the LN prefix, but a key element in the naming is still the logical device name.

By default, a logical device name – the top level of the naming hierarchy – is created from the IED name and the LD instance name which is declared in the SCL file from the IED manufacturer. That LD instance name groups the logical nodes into logical devices. So, the logical device name depends on the product specific naming (LD instance name) and on the IED name. Alternately – since Ed 2 of IEC 61850-6, the system integrator can choose a logical device name which replaces the concatenation of IED name and vendor defined LD instance name.
When you choose the approach with the logical device name configured in SCL (as replacement of the concatenation IED Name – LD instance name, you need to be aware that the logical device name you select needs to be unique in your system. So, that cannot be applied on the ICD (Template) level – it needs to be applied on the instance level.
Using a logical device name does not yet provide the full flexibility to create vendor independent names as the names depend on how the logical nodes are grouped into logical devices. The logical device is where in the mapping the split is made between an MMS domain and an MMS named variable. The grouping of LNs in logical devices is typically vendor predefined.
So, a fully vendor independent naming of the communication address can only be achieved if the structuring of the LNs into logical devices is as well flexible and can be determined by the user. And this is currently not a capability declared by the standard.

Is that a real issue? Probably not! While it makes sense, to keep the communication address as close as possible to the user naming – that may help with low level debugging which we try to avoid anyway – SCL provides other possibilities like description attributes, to create a user meaningful name that can be exported for SCADA systems to present the signal in a user-friendly way. And from the view of a substation – control center communication, once IEC 61850 is used there, the specification provided in IEC 61850-90-2 allows a complete remapping of the naming structure and then it is possible to create communication addresses that are completely vendor independent. This allows from a SCADA engineering perspective, to apply a unique addressing scheme to all substations – independent of the realization details.
All the discussed aspects apply between the system configuration tool (SCT) and the IED configuration tool (ICT), once the SCT has imported the ICD file and creates the SCD file. In that SCD file, it may have changed the LN prefixes and it may have added a logical device name to be used instead of the IED Name – LDInst concatenation.
But there are other possibilities, that are currently beyond the scope of the standard which happen during the specification process that we recently tested with success. A utility is creating an SSD file with virtual IEDs and the vendor then provides an ICD file which is a one to one copy of the virtual IED. This requires a flexibility from the ICT to map the IED internal data model into the data model specified by the user and create out of that an ICD file. With that, a vendor independent naming can be achieved without the need to change prefixes or LD names in the SCT, as the ICD already has the desired data model.

Is that still top down engineering? I would say yes - but it is not the top down engineering that happens between the system configuration tool and the IED configuration tool as discussed in the standard. It is a top down engineering that happens at an earlier stage in the process – at the specification stage. It happens between the system specification tool and the IED configuration tool.
So, as you see, there are many flavors of top down engineering. Let’s play with them and use them to get the maximized benefits.



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. 

Relion advanced protection & control.
BeijingSifang June 2016