IEC 61850-9-2 Sampled Values In Use

Quite often people ask me about the application of sampled values according to IEC 61850-9-2 (9-2LE). The sampled values require very solid products (publisher, Ethernet Switches, and subscribers). The recent years have shown that the technology has matured to an extend that applications are already available or underway.

Please find useful links:

Click HERE for the paper:

Test and Evaluation of Non Conventional Instrument
Transformers and Sampled Value Process Bus on Powerlink’s
Transmission Network

Click HERE for a related publication:

Australia Leads With Process Bus

Click HERE for the 9-2LE guideline published by the IEC 61850 community.

More and more 9-2LE compliant IEDs are tested and certified.

There are more than 400 IEDs (Server, clients, publisher) that have been certified by the UCAIug:

Source: UCAIug

What’s about subscriber to sampled values?

Click HERE for various protection IEDs implementing the subscriber role for sampled values, e.g., Alstom Distance Protection Relay P446, …

More to come.

IEC 61850-9-3: Precision Time Protocol Profile for Power Utility Automation

IEC TC 57 has published the other day:

IEC/PAS 61850-9-3 (57/1551/PAS):
Communication Networks and Systems for Power Utility Automation –
Part 9-3: Precision Time Protocol Profile for Power Utility Automation

Voting terminates on 2015-05-01

The intent of this publication is to present a widely agreed technical solution for a precision time protocol (PTP) profile of IEC 61588:2009 applicable to power utility automation. There is urgent need in the power industry for a appropriate profile for power automation application to be defined in IEC 61588. This PAS (Public Available Specification) is intended to temporarily be used as a reference.

This allows to meet the highest synchronization classes of 108 IEC 61850-5 and IEC 61869-9.

IEC 62351-9: Cyber Security Key Management for Power System Equipment

IEC TC 57 has published the following draft standard:

IEC 62351-9 Ed.1 (57/1565/CD):
Power systems management and associated information exchange – Data and communications security – Part 9: Cyber security key management for power system equipment

Closing date for comments is 2015-07-03.

IEC 62351-9 specifies how to generate, distribute, revoke, and handle digital certificates and cryptographic keys to protect digital data and its communication. Included in the scope is the handling of asymmetric keys (e.g. private keys and X.509 certificates), as well as symmetric keys (e.g. session keys).
This part assumes that other standards have already chosen the type of keys and cryptography that will be utilized, since the cryptography algorithms and key materials chosen will be typically mandated by an organization’s own local security policies and by the need to be compliant with other international standards. This document therefore specifies only the management techniques for these selected key and cryptography infrastructures. The objective is to define requirements and technologies to achieve interoperability of key management.

Data and communications security are very crucial for the future power delivery system – take the various documents of the series IEC 62351 very serious!

How to Migrate to Internet Protocol Version 6 (IPv6)?

IEC TC 57 just published a new draft document for a future Technical Report:

IEC 62357-200 TR (57/1563/DTR):
Power systems management and associated information exchange –
Part 200: Guidelines for migration to Internet Protocol version 6 (IPv6)

Application: Utility communications using utility-owned and leased networks, including, but not restricted to communication within substations, from substation to substation, from substation to control center / maintenance center, control center to control center, energy management systems, synchrophasors, distributed and bulk energy generation and storage resources and (including fossil fuel plants and renewables) wind-, and solar power generation, storage, demand side management, and demand response for distribution level consumers / producers.

This draft Technical Report addresses the issues encountered when migrating from Internet Protocol version 4 (IPv4) to the Internet Protocol version 6 (IPv6). It describes migration strategies, covering impact on applications, communication stack, network elements, configuration, address allocation, cyber security, and the related management.

The migration will add new need and require more skills of the engineers. It is highly recommended to have some people that start learning the changes that will come during the next 30+ years.

Maybe you start with a small group as we did in the standardization process 15+ years ago in Seattle (WA) in 1999:

Teamwork makes the dream work!

Be aware that the “network infrastructure” becomes one of the most crucial basics for all other infrastructures.

Would your company’s communications infrastructure survive a blackout like the one in The Netherlands today (2015-03-27)?

“Dutch electricity network administrator Tennet says that a large part of North Holland province, which is home to some 2.7 million people, was hit by the outage.

Tennet said on its Twitter feed that the outage was caused by a “technical fault” a high-voltage power station in the town of Diemen, just outside Amsterdam.”

Source: The Independent

I hope it was not caused by an “unknown” GOOSE Trip Message! … Which – at least – would mean it was not related to TCP/IP … IPv4 or IPv6. I am kidding! … a bit.

Out-Of-Range Quality Flag and Reporting Quality-Change Event

In addition to the following two discussions that contain a view on measured values:

What Does Complexity of a Protocol Mean-
Are you prepared for the Solar Eclipse 2015 on March 20-

I will now look into the possibility to automatically monitor and report the limit violation of a measured value using standard configuration of IEC 61850 Information Models (LN STMP1), Data Sets and Report Control.

There are two options to report the temperature value reaching the maximum possible value: using the quality information of the “Tmp.q” (configured by the configuration of the “max” value in “rangeC”) or the “Alm” (configured by “TmpAlmSpt”) as depicted in the following figure:

We need to configure a Data Set and a Report Control Block for each case. In case of using “q” we have to communicate and interpret the “q” value “questionable and out of range” (which is a bit pattern!). In case of using the alarm data object “Alm” we just send and receive a simple Boolean value “True”. There is no need to interpret a bit pattern.

For machines it should be no big difference to analyze a bit pattern or a Boolean value.

Both approaches would provide the information that a measured value is higher than a specific limit (max or alarm limit). Which one you would like is up to you.

It is recommended that for specific domains it is specified in a “profile” document, which option to use. Maybe you want to use both: the “q” for asset management and the “Alm” for Automation functions to automatically start a cooling system. The “Alm” could easily be used for GOOSE messaging to inform a wide range of subscribers of the alarm …

The nice thing is that you can easily configure the multiple options just by SCL !! No programming needed – if the values of “q” and “Alm” are provided by the application.

Lesson learned: First define your need – then design the behavior of your Report and GOOSE messaging. If you don’t know what you want to accomplish, no standard can help you.

Germany Survived the Solar Eclipse 2015 on March 20

During the last days and months there were a lot of discussions and news about a possible blackout during the Solar Eclipse 2015 today. The operators (and the nature) were quite well prepared for the event.

Lesson 1 learned: Nature and Operators did a good job!

Is there another lesson learned? Sure!

Due to the fact that the universe is not made by human beings, we could predict the movement of the sun, the moon and the earth … and thanks to mathematics we could calculate the impact of the sun on a sunny day like today …

Source: ENTSO-E; click HERE for further details provided by ENTSO-E.

The first maximum of PV power feed-in of 13.3 GW was at 9:45 h today. One hour later the minimum feed-in was 5.1 GW at 10:45 h.

Source: SMA, click HERE for the online data (then select March 20, 2015).

Between 10:45 h and 11:45 h the feed-in grew by 11,7 GW. That means 195 MW per minute or 3,25 MW per second. The maximum of the day was 20.3 GW at 12:45 h.

Source: SMA, click HERE for the online data (then select March 20, 2015).

Note that the forecast was very accurate, as can be seen in the following diagram:

Source: TransnetBW; click HERE for the online data.

The forecast of March 13, 2015 (one week before) was some 700 MW higher than the actual value for 13:00 h, as can be seen in the following figure:

Source: TransnetBW; click HERE for the online data.

The transmission companies have spent a lot of money to get a very precise forecast for today – and it worked fine. But these efforts were taken because it was a remarkable day. The forecast may become better – they are still modeling the physical world with laws set by the creator of the nature. The future power system will be impacted by more man-made “laws” that focus more on profit than on physics.

How many power plants have been used today to control the frequency and balance the load and generation? Maybe a few hundred. These power plants are well equipped with remote terminal units and communicate through IEC 60870-5-101 (and some with -104).

The control center are able to control remotely in the context of schedules plant for the day.

Another question is: What if we have to control Millions of decentralized resources (in some years)? What if we have not only 40+ GW Wind Power and 50+ GW PV power installed?? Who will provide the needed schedules for millions of feed-in points? Who and how will we control millions of these resources?

And how will we guarantee that the needed communication links between millions of intelligent devices will operate in a disaster situation? Note: TODAYs Solar Eclipse was far away from a disaster!

And what happens if somebody manipulates the information and information exchange? Even if we limit the active control commands to a very few or forbid them at all. We need to exchange at least situational information: current, frequency, voltage, power factor, or … Who guarantees that the values exchanged can be trusted?

Can we then trust that we know all communication connections that end in a power plant? You would be surprised if you would start to list the communication assets. As an expert recently said: “I have had the same experience as … with respect to finding "unknown" remote access connectivity at almost every facility I have assessed. These include dial-up modems, wireless access points, and network interface cards that IT and Corporate Engineering did not know existed.” Somebody else said: “At another facility we were told that external connections were always unplugged, but we were able to call the equipment at the phone number we saw posted.”

The future of our power delivery system is dependent on millions (instead of hundreds) of power resources, and on human beings that may loose the control over the communication infrastructure or that may compromise the communication and control systems.

Lesson 2 (to be learned by all): Take the communication, secure communication, control, secure control, impact of the physics on the power system and other aspects MORE SERIOUS! Think always how to apply standards – I mean real standards like IEC 60870-5-104, IEC 61400-25, IEC 61850, or DNP3.

There is a lot to be accomplished at the engineering level! Power is more than Euros and Dollars … let’s do the job together. We need you all.

All people that have read to this end will agree with me (at least in general).

Thanks for taking your (spare!?) time.

What Does Complexity of a Protocol Mean?

There is always a discussion on one protocol being more efficient and less complex than another or all other. Does this discussion help? I don’t think so.

The key issue is the “SYSTEM” – which is MUCH more than a protocol.

Let’s discuss briefly the configuration of a device with regard to reporting a value based on a deadband configuration and the range and multiplier of an analog value.

Usually the deadband values and range configurations and other crucial information are specified in a pdf file or – if you are lucky – in an excel sheet or XML file. So, to interpret a message the receiver has to know the configuration. The tables contained in the pdf file (below) have to be translated by somebody manually … and how can I find out in 10 years from now, what the limits of the Band width voltage are? Hm. No idea?! Usually you cannot ask the device. So, what now?

I am sorry, if you don’t have the pdf you may guess what the limits are – but you don’t know. Maybe somebody from the vendor is still there and can answer the question.

Example of a DNP3 SPECIFICATION - DEVICE PROFILE

Excerpt on deadbands and configuration:

A good thing is, that many vendors publish these files. Sur, you never know if they are up-to-date or applicable for your device you installed some time ago.

The information models of IEC 61850 provide dedicated attributes for a value that provide these meta data like deadband configuration, min, max, multiplier, SIUnit. These attributes could be used in the corresponding SCL file only or they could additionally be exposed by the device and made accessible through a simple read message.

With IEC 61850 in place we could easily expose the limits of power production and load and further attributes. The logical node MMXU (IEC 61850-7-4) could be used for the limits in which a value is valid:

Data Object TotW of class MV (measured value, IEC 61850-7-3) - Total active power (total P)

could provide the actual value, quality, range, Scale, limits, units, deadband in the details provided through the MV CDC:

mag.f	deadband filtered AnalogueValue coded as floating point
q	Quality
range	ENUMERATED normal|high|low|high-high|low-low (out of range would change quality value)
rangeC	RangeConfig: hhLim hLim lLim llLim min max
sVC	ScaledValueConfig (scale and offset) for Integer values
db	Deadband filter in % of range (min – max)
units	SIUnit and multiplier

min: the min (minimum) attribute shall represent the minimum process measurement for which values of i or f are considered within process limits. If the value is lower, q shall be set accordingly (validity = questionable, detailQual = outOfRange).

max: the max (maximum) attribute shall represent the maximum process measurement for which values of i or f are considered within process limits. If the value is higher, q shall be set accordingly (validity = questionable, detailQual = outOfRange).

In our case, the TotW for the CHP generator may be limited between 0 W (min) and 35 kW (max). A value of “minus 600” MW would have to be flagged as questionable and outOfRange !! Negative values and values higher than 35 kW would be flagged out of range!

The receiver (a control center) could check the limits of the values (either by reading the range configuration online by a service or getting it from the corresponding SCL file). It could figure out that the range is 0-35 kW. Even if the gateway (RTU) would send “minus 600” MW (load) … the CC could understand that this is a bad value – recommended not to use.

The ScaledValueConfig exposes the scale factor and offset value – required to interpret an integer value.

The deadband db defines when to report a new value: when a change of the value is “+/- db of the range”: a range of 100 A and db=2000 (2 %) means –> every change of 2 A will be reported; the last reported value was 78 A, then the next report will be issued when the value reaches 76 A or 80 A.

The units contain the SIUnit (e.g., A) and the multiplier (10**0 –> 1).

The meta-data of the measured value serve as a means to help interpreting the plausibility and validation of a value communicated.

To focus on a message “Report a changed value based on a deadband configuration” and discuss which protocol does it more efficient is not helpful! Modbus can communicate the total Power – as can any other protocol. But: HOW to INTERPRET a received value? Is the value within the limits defined for an application? Is the value given in W, kW, MW or GW??

A system should be able to provide more than just A value – all crucial meta data that help to interpret the value are needed in any case. Either you get it – or …

Please focus on the “System” – a holistic approach is what we need.

This blog post will likely not stop protocol efficiency discussion … ok. And?

If it makes you happy when you discuss protocol issues … do it.

Are you prepared for the Solar Eclipse 2015 on March 20?

Why raise such a question on this blog that is about standards like IEC 60870-5-104 and IEC 61850 …? These are two good questions. Let’s discuss them briefly.

The Solar Eclipse 2015 and its impact on the power transmission system is discussed these days. The crucial issue is the minute-to-minute power gradient that may exceed between minus 400 MW/minute and plus 700 MW/minute; the highest gradient occurs when the PV in-feed returns at the end of the phase. This gradient may be managed by the TSO or not – who knows. We know it at lunch time on March 20, 2015.

There are many recommendations on the web, how to get prepared: having water, food, … for up to 10 days or so … I hope we will not need these.

@Question 2:

There is a need for the TSOs (just four in Germany!) to relay on good measurements from all-over in the grid and secure control possibilities to manage power plant in-feeds and substations. I guess they have good communication systems they can trust. These systems have been developed over many decades. They are tested and run reliably. Still. But what happens in future where we will have hundreds or millions of technical systems (embedded controllers …) that contribute to the system view and management?? Is this an issue at all?

Yes, it is a crucial issue. Let me discuss the following real-life incident reported last week:

A gateway in a virtual power plant provides the measured load on the network connection point of a CHP (combined heat and power) system. Normally the CHP feeds power into the network. But all in a sudden the VPP/TSO received a signal telling them a jump of the load from 0 MW to 600 MW!! Should the control center responsible for that part of the grid act or not? Hm. If this would be a real jump then it would have to react.

(Un)Fortunately the 600 MW jump was just a jump in the Value communicated!! It was caused by an error in the gateway (RTU kind of device). Was this value plausible? No. Because the CHP could just feed-in – not draw that much power from the grid.

With IEC 61850 in place we could easily expose the limits of power production and load. The logical node MMXU could be used for the limits in which a value is valid:

Data Object TotW of class MV (measured value) - Total active power (total P)

could provide the actual value, quality, range and the limits in the details provided through the MV CDC:

instMag.f	AnalogueValue coded as floating point
q	Quality
range	ENUMERATED normal|high|low|high-high|low-low (out of range would change quality value)
rangeC	RangeConfig: hhLim hLim lLim llLim min max

min: the min (minimum) attribute shall represent the minimum process measurement for which values of i or f are considered within process limits. If the value is lower, q shall be set accordingly (validity = questionable, detailQual = outOfRange).

max: the max (maximum) attribute shall represent the maximum process measurement for which values of i or f are considered within process limits. If the value is higher, q shall be set accordingly (validity = questionable, detailQual = outOfRange).

In our case, the TotW for the CHP generator may be limited between 0 W (min) and 35 kW (max). A value of “minus 600” MW would have to be flagged as questionable and outOfRange !! Negative values and values higher than 35 kW would be flagged out of range!

The receiver (a control center) could check the limits of the values (either by reading the range configuration online by a service or getting it from the corresponding SCL file). It could figure out that the range is 0-35 kW. Even if the gateway (RTU) would send “minus 600” MW (load) … the CC could understand that this is a bad value – recommended not to use.

The meta-data of the measured value serve as a means to help interpreting the plausibility of a value communicated.

IEC 61850 models add very useful information to help (a bit) keeping the power flowing. There are many other physical issues to take into account … but information and information exchange plays a crucial role!

What about security for SCADA systems?

Since the early 80s we have discussions on open systems. I remember well people saying in 1984: If you want open systems – you must be crazy. True! If you don’t shut the doors of the access and let only those in that are allowed to.

There are measures to secure the access – but they have to be implemented and used. There are a lot of concerns about embedded systems on the internet and security.

Read this up-to-date story – and you may not sleep tonight:

Journalists warned system owners and Norwegian NSA of 2500 critical data flaws

How two journalists set out on a mission to test the data security in the whole of Norway

Excerpt:

“Thus far, they have found:
• 290 vulnerable control systems, in banks, schools, nursing homes - and a military camp
• 2048 surveillance cameras in private homes, night clubs, shops and restaurants
• 2500 control systems connected to the Internet with minimal or no security
• 500 of these control industrial or critical infrastructure
• Thousands of data bases and servers that give away content without passwords

These are all found in Norway. Guess if it is any better in your country?”

Click HERE for the report.

And YOU? Become more serious about security!!! For the good of you and all of us – all over.

And do not blame IEC 61850 not providing security measures! It has: IEC 62351 shall be applied – but you gave to do it! Do it!

http://blog.iec61850.com/2015/02/standard-iec-62351-3-communication.html

How to get prepared using IEC 61850?

How to get prepared using IEC 61850? This is one of the crucial questions these days. Fortunately there is an increasing number of organizations that understand the challenge with the IEC 61859 technology – and get training and education.

The A.C. electric power system is a very dynamic physical system. Could you remember the exam on Electro Dynamics when you were a student? Oh, don’t remind you … it was (is) a horror for many electrical engineers – also for me. Even some 40 years later, we have the same challenge with the dynamics of the electrical system. It is more complex these days because of the integration of thousands and millions of “power stations” into the system. The need for a good base knowledge of the electric system COMBINED with the need to get familiar of using an increasing information exchange to monitor and control the electrical system will be the prerequisites for the future electrical engineers.

I  have seen several utilities, vendors, and institutes that are very serious when it comes to the use of IEC 61850 based IEDs in substation designs. A lot of money has been invested in building network simulation systems that can be used in a lab to test IEC 61850 based protection, control and remote monitoring schemas. This is the only way to prove the concepts for a particular application domain. The financial situation of many utilities does not allow to invest into a comprehensive lab.

The education of students is very crucial. I was quite happy to read about a new lab at the Victoria University (VU) in Melbourne. They are “about to become a cornerstone for integrating smart grid technology into Australia’s electricity supply market, with the development of one of the world’s only (if not first) Zone Substation Simulator Centre (VZSSC).

The Centre will simulate 66 to 22 KV substation environments (specifically a two-transformer zone substation with dual MV buses), control and protection schemes using the IEC 61850 technology standard for the automation and control designs.
Whilst a breaker and a half configuration will define the sub-transmission side, the protection and control setup will encompass a specific X & Y protection scheme.”

Congratulation to Dr Akhtar Kalam and Graeme McClure that succeeded in convincing enough people to spend money to make this happen!

There is another group of people that need education in IEC 61850: Senior and junior protection and electrical engineers that have long term experience in substation automation, protection, and remote access.

Many of these engineers may have heard some stories about the use of IEC 61850 for power systems – but may have only a chance to read the many parts of the IEC 61850 standards … good luck. Reading the standards? It is more efficient to get a training conducted by senior engineers that could help you to speed up.

Click HERE to see what two senior engineers provide: Protection engineer Andrea Bonetti (FMTP) and communication engineer Karlheinz Schwarz.

Click HERE for a full description of the lab at the Victoria University (VU) in Melbourne.

Additional information of using IEC 61850 and IEC 61499 in Distributed Power Systems .. zone substations …:

Distributed Power System Automation With IEC 61850, IEC 61499, and Intelligent Control (Neil Higgins, Member, IEEE, Valeriy Vyatkin, Senior Member, IEEE, Nirmal-Kumar C. Nair, Senior Member, IEEE, and Karlheinz Schwarz, Member, IEEE; IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS, 2010)

Multi-agent Smart Grid Automation Architecture based on IEC 61850/61499 Intelligent Logical Nodes (G. Zhabelova, V. Vyatkin, Senior Member IEEE; IEEE Transactions on Industrial Electronics, 2011)