Question & Answer: Are “valKind” and “valImport” related?

The configuration of systems and IEDs with IEC 61850 tools (system tools, IED tools, protocol stacks) is a challenge for people involved in power system protection, monitoring, and automation.

I guess that you have some experience with the many rules and the underlying philosophy that are crucial for the correct operation of interconnected IEDs.

Quite often it is obvious how to apply a given rule in the configuration language (IEC 61850-6 SCL). First of all: You have to take into account the standard document AND the green tissues!

Example on the relation between “valKind” and “valImport”. Tissue 804 introduces the new attribute “valImport” in an SCL document:

http://tissue.iec61850.com/tissue/804

The need for that “valImport” attribute is discussed at the bottom of the tissue 804. The solution is well defined.

The two attributes can be applied for data attributes configured in an SCL file. There are two different categories of data attributes:

1. Models of “process” related information, e.g., scale factor of an Integer modeled measurement.

2. Models of “communication service” related information, e.g., Trigger options or integrity period of a report control block.

If in a SCL document (SCD) the process related values (e.g., scale) SHALL be fixed, these values must be set and declared as fixed. It is not allowed by an IED tool nor online to change these (fixed) values: Here are the corresponding attribute settings (valKind=RO AND valImport=false).

We have to be careful with rules (not defined in the standards) like the following:

If valKind=Set THEN valImport=true (if I can overwrite a value with a service, it makes sense to allow to configure a value at tool level; it may be useful for communication service related information of a control block, but not for process related information).

Be careful with the combinations of these two attributes … they are independent of each other. And: Not all tools may understand the philosophy below.

What are the Benefits of IEC 61850?

The question “What are the benefits of IEC 61850” has different flavors and multiple answers – it depends on what are you looking for. If you are looking just at the communication protocol, there are answers like:

1. The client/server protocol (MMS) is a unified solution standardized some 25 years ago. It is a stable standard – unlikely to change in the future and accepted all over for many years.
2. The GOOSE messaging is very unique and provides real-time information exchange in the msec range – accepted all over
3. The Sampled Values messaging provides a unique solution for exchanging samples of currents, voltages, vibration measurements accepted all over.

If you are looking at the information models, there are really many crucial models defined and in use. No other standard (I am aware of) has such a rich set of information models that expose process information in a standardized way – all over accepted.

There is – of course – the crucial issue on the configuration language. In this post we will discuss the benefit of a unified model that allows to hide the different vendor-specific signal lists for Modbus communication in two different power quality meters. In the end, the unification of specific information profiles (or subsets) for, e.g., the electrical measurements makes IEC 61850 different compared to any other solution I know.

The power quality monitors used are: Janitza UMG 604 and Acuvim II. Both meters provide many measurements of the electrical system. The signals can be communicated by Modbus. Usually each vendor has a different approach to define the lists of signals – and especially the indexes used for the vary same signal is quite different and have to be mapped manually to any application – again and again. There is no way to agree on a single unified Modbus signal list that can be applied all over. The next figure shows the two devices, their signal “phase voltage” with different identifiers and indexes.

The unification of the information model is implemented in a simple gateway (com.tom BASIC 5.1). The gateway is based on a WEB-PLC that maps the incoming Modbus signals to IEC 61850 models. The IEC 61850 model uses the same logical node class and type. The type MMXU_0 is the subset of the MMXU class used in this application (of four data objects – as can be seen in the icd file). The instance MMXU1 can easily be “copied” to build a second instance: for the Acuvim II meter. Both instances use a unique MMXU logical node type (contained in the icd file). The model can be used to configure the IEC 61850 server device and an IEC 61850 client (in this case the IEDScout) as shown in the next figure.

The gateway solution is reasonable in case just a limited number of applications need the information communicated by IEC 61850.  The next step could be to integrate the “gateway” into the meter housing, as shown in the next figure:

The “heart” of the gateway (we use) is the Beck IPC@CHIP controller that could be applied as a subsystem in the meter. It manages the complete IEC 61850, IEC 61400-25, IEC 60870-5-104 or DNP3 communication.

The IEC 61850 models are the same as before in the case of using a separate gateway box. From a client point of view there is only one difference: there are two IP addresses and two IED names to take into account.

The configuration of the client could benefit from the unified information model contained in a standardized machine readable format (.icd). When you google for power meters with a Modbus interface (or any other fieldbus-like) interface you will get as many different signal list as solutions. In our case we can easily unify the information that comes from many different meters.

By the way, the unified model can be fed not only by a Modbus communication interface. Any other signal list communicated by the myriad of solutions could easily be unified! It does not matter how many different protocols you have to take into account – the very same IEC 61850 profile could serve them all. Define it once and use it for ever and all over.

The WEB-PLC based solution explained here is available – I have tested the concept with several devices: meters, monitoring devices, control devices. This approach could be applied right away – and you pay while you go. To get started with a extra box is in the range of some hundred Euro plus some time to understand the approach and learn how to get started with the product. The IPC@CHIP including IEC 61850 client and server (GOOSE and SMV), IEC 60870-5-104 server, and Modbus client costs less than 100 Euro – too cheap to ignore.

Let people define new protocols and … IEC 61850 can unify them all! The next days I will post a report on a hierarchical system with a Janitza UMG 604 and fan heater as the process, a com.tom device to monitor and control the process (with an IEC 61850 server), an a com.tom on top that could be used as a (proxy) gateway to the underlying com.tom (providing an IEC 61850 client, IEC 60870-5-104 server and an IEC 61850 server). The gateway interoperates in a plug&play manner with the underlying IEC 61850 IEDs.

I don’t fear the following situation:

nor this …

It is a change for IEC 61850 to unify the proliferation!

More to come shortly – stay tuned to this blog.

I had to wait almost 30 years to have a real simple and easy to use “MAP” solution running on my desk:

The MAP/TOP Demonstration in 1986 was too early! Definitely!

Best wishes for 2014

As a very busy year comes to an end, I want to THANK YOU ALL for the interest in Standards like IEC 61850, IEC 61400-25, IEC 60870-5-104, … as well as your interest to discuss the many opportunities to use these standards and the challenges in the implementations and conformance tests.

More than 400 experts have been trained during 2013 in more than 20 courses all over. The attendees are really looking for more details and how to reach a higher level of interoperability. My long-term experience is growing quite fast … especially in the area of interoperability issues …

I wish you a healthy and successful year 2014 – especially that you can live in peace with your family, friends and all other people you have to meet in your life.

I look forward to working with you next year … especially when you have any issue regarding IEC 61850, IEC … interoperability.

Please take some time to relax and re-charge your batteries.

We are all doing fine … just cut the lawn this afternoon (Dec. 23, 2013) … it was quite warm here in Karlsruhe: 13 °C … no snow and ice until 2014 !!

Best Regards,
Your Karlheinz Schwarz

Using ConfRev to report a change of value

The configuration revision is a very useful information for clients (Reporting) and subscribers (GOOSE and SV). It is highly recommended that a receiving IED marks the received values as invalid in case the receiver expects ConfRev=X but receives a message with a value unequal X.

The service Reporting (or GOOSE) could be used to inform receivers that there is a change in the ConfRev – long before it may receive a message with a different (incremented) value.

By the way, the functionality to “monitor” changes of control block attribute values is called “Service Tracking” and is defined in IEC 61850-7-2 Edition 2.

The Control Block Attribute ConfRev needs to become a member in a data set. This data set may have all ConfRev attributes of all control blocks as members. So, if any change is detected, a message is issued (Report or GOOSE message, or log entry posted).

It is not yet specified in IEC 61850 if the change of a value (of the ConfRev) implemented by a re-configuration of the IED (e.g., change of the data set) can be used as a trigger (dchg) to issue a report or GOOSE message or post a log entry. Because this new value may become online visible after the IED restart (to interpret the new SCL file).

It would require that the Control Block stores the last ConfRev value non-volatile; in order to figure out that the new value (from configuration tool) is larger than the old one. This is true for SV Control Blocks only, see §19.2.1.6: “A restart of the IED shall not reset the value.”

See IEC 61850 Tissue # 861.