Ethernet Comes with a Brand New Easy Solution: Single Pair Ethernet (SPE)

Ethernet is well known globally as solution for communication. Ethernet was hated and liked for the last 40 years or so ... there have been alternative solutions developed that were marketed as much easier, faster, deterministic, ... think of Tokenbus (IEEE 804), Profibus, ... and many others.

Now we see a new version: Single Pair Ethernet (SPE). SPE can bring fast Ethernet (up to 1 GBit/s) and power to the field level using just one twisted wire pair ... enabling application of protocols using TCP/IP.

Click HERE for a general description.

Click HERE for a nice presentation by IEEE experts (January 2019)

SPE is a new technology to replace CANbus in automobiles (cars, trucks, busses, ... trains) and fieldbusses. SPE is a layer 1 standard ... so it can be used for Profinet, Ethercat, ... and it could run TCP/IP.

SPE is more intended to replace fieldbus systems ... here my dream of the late 80s becomes true:

Fieldbus Standardization - Another Way to Go

http://blog.nettedautomation.com/2017/05/tsn-fieldbus-standardization-another.html

additional posts related to the topic:

http://blog.nettedautomation.com/search?q=another+way

The use of SPE for connecting sensors to the cloud is to follow a trend ... it may increase the sales of component manufacturers.

When I wrote my Diploma Thesis in 1982 (at Siemens) I was asked to analyze Ethernet ... the idea was cancelled because of the very very expensive MAU ... needed two ... each for 23,000 USD ... total of 46,000 USD ... no way to get approval to spend that amount for a "standard" Diploma Thesis ... 

It took some 40 years to get to SPE - likely the real Ethernet ... ;-)

Too late for me ... just retired this year with 67 ... 

One crucial challenge is here: HOW to SECURE a huge number of end nodes (sensors, actuators ...) directly connected to the clouds or data lakes? Compare the situation with Smart(er) Grids: In Smart(er) Grids it is intended to connect millions of smart meters to the entities (clouds!?) that use the data for billing and further applications like controlling millions of inverters or power users. 

In the German power system there is a requirement to use the so-called Smart Meter Gateway (SMG) to provide highly secure communication channels! 

Click HERE to check what has to be implemented ... many published Megabyte pdf documentation of the required specification like: "Protection Profile for the Gateway of a Smart Metering System (Smart-Meter-Gateway PP)" ... by the German BSI.

It took many years before we have seen the first certified Smart Meter Gateway offered at the market. And be aware: The Administration of this infrastructure is very complex and ... far away from cheap and affordable by "everyone".

Many similar huge "security systems" would be required to connect the billions of smart sensors and actuators through Single Pair Ethernet to some centralized entities ... 

SPE is nice - BUT to build secure distributed systems it is required to develop also new security solutions that are as simple as Single Pair Ethernet!!

We have to look at the complete SYSTEM COST - not just at the possibilities of a new physical layers ... the SPE increases the problems of implementing secure systems, because it is easier and cheap to build a huge mashed network of millions of end nodes ... that may not perfectly secured!

TSN: Fieldbus Standardization - Another Way to Go

Fieldbus standardization has a very long history - resulting in tens of solutions in ONE single standard series IEC 61158. This has been discussed several times on this blog.
The latest decisions in the industrial automation domain could change the direction to go: To get one or two or three ... solutions - based on TSN (Time-sensitive Networking).
It took more than 25 years to implement in principle what I have written in a paper on Fieldbus and Ethernet. When I worked for Siemens Industry in the early 90s, I recommended to use native Ethernet instead of fieldbusses … now we write 2017 – 26 years later:
Click HERE for the paper “Bridging MAP to Ethernet” [PDF, 720 KB, 1991]
Click HERE for the paper “Fieldbus standardization: Another way to go” [PDF, 720 KB, 1991].

25 years of fieldbus wars are likely to end in the near future.
Even the Profibus International Users Group (PI) published the other day in the PI Profinews:
"TSN (Time-sensitive Networking) is a promising new IEEE technology for Ethernet that combines ... PI will expand PROFINET with the mechanisms of TSN in layer 2, retaining the application layer on the higher levels. This makes it possible to migrate the applications to the new technology simply and incrementally and to take advantage of the benefits of an open, globally standardized IT technology.”
Clicke HERE for the full announcement in the Profinews.

It's a pity that it took 25 years to understand that Ethernet is THE solution for the future.

TSN is just another link layer solution - what's about the upper layers? Huuch ... there is still the old fight of various groups that belief that their solution is the best!
PROFINET will keep their higher layers and add the option of OPC UA for higher automation levels to the cloud. So, they are recommending a compromise - which ends up in many higher layer solutions on TSN.

ABB, Bosch Rexroth, B&R, Cisco, GE, Kuka, NI, Schneider Electric, Belden/Hirschmann and Phoenix Contact are fighting for a SINGLE combination: TSN and OPC UA.

In the meantime we have - for more than 20 years - a SINGLE combination for the electric power (and energy) market: IEC 61850 with Ethernet and MMS (for client/server communication) supported by hundreds of vendors and users worldwide. AND: IEC 61850 has a huge basket of object models and a configuration language! What is being communicated through OPC UA TSN?

A finished solution (Ethernet/MMS some 25 years ago) is better than a perfect one that will never be accomplished - even not with TSN plus XX, YY, ZZ, ...!

This lets IEC 61850 look very good!

If you need your Profibus or Profinet data being communicated by IEC 61850, check HERE for Gateways.

Interoperability and Replacement of an IED by another one

The other day somebody from the user community posted a comment on this blog. The issue discussed is on Interoperability and Replacement of an IEC 61850 compliant IED by another one:

"That is exactly what we users want: not just be able to have different IEDs from (possibly) different vendors cooperating in our substations, but also be able to replace an IED by another one that is functionally equivalent (or superior, or maybe just similar, this being the utilty’s internal issue) regardless of what the other system components are, and in the easiest possible way."

First of all, the Replacement of an IEC 61850 compliant IED mainly depends on the implementation of the standard (which subsets, ..., restrictions) and on the configuration of the system.

Replacement could be very easy but also be a bit complicated. One example shows the impact of the implementation (restriction) and one shows the impact of the configuration.

Restricted implementation: Suppose that an IED A (to be replaced) has 10 Logical Devices to model the application. IED B (to replace IED A) has only the possibility to support five (5) Logical Devices; the restriction is done during the design of the IED.

The system engineer has configured the IEDs and the information flow between them, e.g., the flow from IED A to other IEDs. The designed information flow between IED A and other IEDs is like a Contract. This contract says that IED A has 10 LDs and underlying LNs and DataObjects. The LD name are used to designate the DataObjects; the LN-Reference contains the LD-Name. A DataSet could have members from all 10 LDs (this could be "written" in the contract).

If the IED B has only five (5) LDs then the designation of the DataObjects will likely be different - it requires a modified Contract! The Clients (Subscriber) have to take these changes of the designation into account. This may require a re-configuration of the Clients (Subscriber).

Click HERE for a PIXIT document providing some information about an IED, e.g. restriction of GOOSE messages that can be sent (<= 16) ...

Don' forget: Everything is limited!!

Configuration of the system: Even if IED A and IED B have the same signal designations (same model) it could be that the "old contract" defines a flow as follows: the information to be reported or goosed is defined in a very big DataSet (e.g, of 100+ members). IED B may only support DataSets with a maximum of 50 members. As a consequence the "contract" has to be modified to create two (or more) DataSets and two or more ControlBlocks. The Clients (Subscriber) have to take this into account.

The "easiest possible way" means to apply the same "contract" (flow configuration) for IED A and IED B. If IEDs would be quite flexible with regard to the "contracts" then a replacement would be quite easy.

By the way, the question, which "contract" we could write depends on the vendors' implementations and the way how people configure systems, BUT not on the standard!

The utility requirement could be modified as follows: "to replace an IED by another one that is functionally equivalent (or superior, or maybe just similar, this being the utilty’s internal issue) AND that uses the same "Contract" of the information flow between the two IEDs, regardless of what the other system components are."

IEC President Wucherer talks about the Electric Future

The new IEC President, Dr Klaus Wucherer talked to the IEC Council recently.

According to the IEC e-tech website (2012-01-28): “Wucherer underlined that as an engineer and industrialist he has been in contact with the IEC in one way or another throughout most of his working life. He contributed to IEC work through his company and the National Committee and was an industry customer for IEC products and services. … Wherever there is electricity, the IEC needs to be involved.” I my opinion: IEC is already deeply involved – many experts have to learn this.

Dr Wucherer was my boss at Siemens Automation and Drives when I started my consultancy business 20 years ago – he was in Nuremberg and I was in Karlsruhe. The reason I became a consultant was this: Dr Wucherer asked me three times to move from Karlsruhe to Nuremberg – I decided to stay in Karlsruhe and work in the standardization as a consultant. Dr Wucherer, colleagues of mine and I were deeply involved in the national, European and international standardization of Fieldbusses and MAP. Dr Wucherer supported the standardization work in the 80s and 90s. We agreed that the future would require true international standards for information exchange.

As a Siemens employee under Dr Wucherer I wrote two remarkable papers on the standardization: one about the future of Fieldbusses and one about MAP in 1991:

Click HERE for the paper “Bridging MAP to Ethernet” [PDF, 720 KB]

Click HERE for the paper “Fieldbus standardization: Another way to go” [PDF, 720 KB].

I would extend his statement “Wherever there is electricity, the IEC needs to be involved” to

Wherever there is electricity, the IEC 61850 needs to be involved!

Click HERE for some crucial information models for the electricity defined in IEC 61850-7-4 that demonstrate the importance of the above extended statement.

The “electricity world” is likely to prevent the proliferation found in the industrial automation domain’s fieldbusses. If the many fieldbus consortia define their fieldbus specific profiles for the electric world then we will get as many information models as fieldbusses! Or?

Click HERE to see bunch of 60+ fieldbusses in ONE IEC standard in 2008: The IEC 61158.

MegaWatt Needs Smarter Megabit/s

What do we need? Huge countries need many MWatt (unit of power) to survive. To get the power whenever we want to use it, we need more “Smart Mbit/s” (“smart” data transfer rate in Mega bit per second). That means: more communicating devices … maybe tens of Millions in some time down the road. What do 1,000 MegaWatt (= 1 GW) and 1,000 Mbit/s (= 1 Gbit/s) have in common? These are huge numbers! And more: We need them both in the near future! The crucial issue is here: One needs the other. Zero GW means Zero Gbit/s and Zero Gbit/s means Zero GW.

Yes, you got it! The two are becoming increasingly interdependent!

There is (mainly) ONE medium to carry power: wires. There are hundreds or even thousands of media to communicate information! Guess you could not count them all. In order to keep the cost for the future power delivery system reasonably low, we could and should think of preventing the proliferation of communication systems. Guess you agree. But: Which solutions are worth to use? No doubt: IEC 61850, IEC 60870-5-104, DNP3, Modbus, … are those that would do a good job!

I would be very happy to have as many communication systems as we have power delivery systems: DC 24V, DC 48V, 3 phase AC 110V/60Hz, 3 phase AC 240V/50 Hz, … and a few more.

Clark Gellings (one of the world’s leading experts on the electricity system, ERPI Palo Alto) talked in a podcast about “The Future of the Power Grid”. He talks about crucial aspects of the future power systems. Key issues (from my point of view) are summarized in the following three points:

Question:
“So what are a few of the things that will have to happen between now and 50 years from now to make your vision of the grid a reality?

Clark Gellings’ answer:
Well, first, we’re going to need communications standards that allow devices to talk to one another, so that we don’t have the problem we have now. For example, in buildings, the electronics that are being used have as many as 28 different communications architectures. And so one building technology that might control some new thermal storage unit you have may not be able to talk to another device in that building.

Number two, the computer system that would control these millions of nodes in any given region of the United States, they don’t exist. I mean, we can control tens of thousands of nodes, and we do now, but we’re going to need to control millions of nodes. So that’s another area of development.

And thirdly, technology. For example, power electronics to fully be able to control, in a very fluid way, the power systems, even to the point of doing things like having the system self-heal, or taking action so as to mitigate from an outage that it sees, even before necessarily the outage has occurred.”

… sounds very expensive!? Not that much … listen to Clark Gellings.

Click HERE to listen to the podcast, find a link to download the mp3, and read the content.

Anyway, the 28 different communication architectures in the building automation he mentions are not so bad - compared to the factory automation with hundreds of solutions!

why not use the IEC 61158 (solutions)? Because it has too many!

IEC 61850 is about to unify most of them (at least at the near-process level where we find the Millions of signals to be shared between Millions of smart devices). And to provide smarter mechanisms to share information.

I hope we can convert more Mbit/s into “Smart Mbit/s”: using them in a smart way. Using smart communication mechanisms (like IEC 61850) will require less bandwidth and smart power systems will need less MW.

Open Source C-Code for IEC 61850

Some six weeks ago I reported about the open source Java code for IEC 61850. The group that developed the Java code has now also published the open source C code.

“In cases where Java is not an option (e.g. if you want to implement a server on very resource constrained systems) you can also consider libiec61850 which is an alternative implementation in C.”

libIEC61850 provides a simple API for MMS. This API is in no way specific to IEC 61850 but provides a generic MMS client API.

This MMS API seems to be an option in case you have to decide to use (on one side) Modbus, DNP3, Fieldbus, or CAN in Automation OR (on the other side) to use IEC 61850. It may help you to get started with IEC 61850. There is no reason anymore not to start with IEC 61850!! The cost argument has gone.

As a Siemens employee I wrote two remarkable papers on the standardization:
one about the future of Fieldbusses/MMS and one about MAP/MMS in 1991:

Click HERE for the paper “Fieldbus standardization: Another way to go”
[PDF, 720 KB].

Click HERE for the paper “Bridging MAP/MMS to Ethernet” [PDF, 720 KB]

It took some 30 years from the fist baby steps to the availability of open source MMS code and other IEC 61850 solutions like the one from SystemCorp that is quite powerful and comprehensive. The time where you have to pay high (“voltage”) prices is over! “High voltage” refers to the application domain high voltage substations – the domain that first used IEC 61850 some 10 or 15 years ago.

Role-based Access Control - On its way to become Standard

IEC 62351-8 is on its way to become an IEC Standard (57/2017/CD):

Power systems management and associated information exchange – Data and communications security –
Part 8: Role-based access control

The part 8 is currently a Technical Specification. This will change in the next step.

The 62 page CD has been published for commenting until 2018-09-28

"This document provides standard for access control in power systems. The power system
environment supported by this standard is enterprise-wide and extends beyond traditional
borders to include external providers, suppliers, and other energy partners. ...

The following interactions are in scope:

• local (direct wired) access to the object by a human user;
• local (direct wired) access to the object by a local and automated computer agent, e.g. another object at the field site;
• direct access by a user to the object using the objects’ built-in HMI or panel;
• remote (via dial-up or wireless media) access to the object by a human user;
• remote (via dial-up or wireless media) access to the object by a remote automated computer agent, e.g. another object at another substation, a distributed energy resource at an end-user’s facility, or a control centre application."

IEC 61850: Work-around for MMS

Very interesting paper just published ... presenting a work-around for MMS ;-)

Integration Method for IEC 61850 into Legacy and Modern PLC Systems

I am a little bit surprised ... when I worked for Siemens (Karlsruhe) I published two papers in the year 1991 (35 years ago!) expecting that MMS could be implemented into a PLC:

Click HERE for the paper “Bridging MAP to Ethernet” [PDF, 720 KB, 1991]

Click HERE for the paper “Fieldbus standardization: Another way to go” [PDF, 720 KB, 1991].

Today we know that MMS could be integrated into PLCs ... 

Gateways work always - definitely.

The expected new work on IEC 61850-8-3 (another mapping than to MMS) would change the situation tremendously:

Communication networks and systems for power utility automation –
Specific Communication Service Mapping (SCSM) –
Mapping to Direct Message Specification (DMS),
JSON Encoding Rules, and WebSockets 

Click HERE for more information on the planned project.

Mapping of IEC 61850 Models and Information Exchange Services to JSON, HTTP, and MQTT

After I published two sketch videos on IEC 61850 information exchange services and the mapping to MMS, I discuss simple interface options for the last meters between a device that implements the role of IEC 61850 server, GOOSE publisher, and GOOSE subscriber, and the underlying huge world of a myriad of other controllers.

The standard series IEC 61850 and IEC 61400-25 (Wind Power Plants) provide a comprehensive set of standardized information or device models (Logical Nodes, Data Objects, Data Attributes, ...) for a wide range of use cases in the electric power domain (protection, automation, supervision, monitoring, control, ...) and for general applications beyond the electrical world. By the way, tell me where electricity is not a crucial resource in factories, buildings, petrochemical plants, homes, ... it is all over ... required 24/7. These series also comprise information exchange mechanisms like Reporting, Logging, Control, GOOSE, Sampled Values, ... mapped mainly to MMS in IEC 61850-8-1 ... other mappings like mappings to XML and XMPP in IEC 61850-8-2 or MMS, Web Services, IEC 60870-5-104, DNP3, OPC XML DA, ... in IEC 61400-25-4. The most crucial part of IEC 61850 and IEC 61400-25 is the System Configuration Language (SCL, IEC 61850-6).

Many applications use only a very small set of models (a few measurements, control signals, and status signals), a small set of information exchange services, and a simple subset of SCL. Critic comes from experts of various domains: Why do I need to have a complex and comprehensive IEC 61850 stack to implement a simple subset of these standard series? Is there another solution? The wind power plant people developing and maintaining IEC 61400-25 believing that five (5) mappings would help in this regard - really? So, the discussion is still going on. 

A very simple solution has been implemented in various projects: Notation of a subset of the information models and the payload of the messages in JSON. The exchange services could be mapped to various transport mechanisms like MQTT or HTTP ...

This approach would KEEP the models as they are - NO mapping required, just another notation (JSON instead of MMS named Variables etc.). Even SCL could be used.

Whenever there is a need to communicate from a device that plays the role of an IEC 61850 server, GOOSE publisher, GOOSE subscriber, to an underlying (likely simple) device (for the last meters) the decision usually is to use some other communication stacks from a set of 100+ solutions like CAN, Modbus, many fieldbusses, EEBUS, Sunspec, ... and private digital solutions, or even wires only ...

Any of these need to MAP from one standard to another standard, e.g., map MyIED/myMMXU1.Hz.mag.f (measurement of frequency) to register 2246 in one application and to 9817 in another ... hm, that is feasible BUT means a lot of configuration and documentation ... outside the definitions and tools provided by IEC 61850. 

A more reasonable approach would be to use JSON, e.g., to define a DataSet (semantically equivalent to IEC 61850 and MMS) and the report message payload as shown in the figure below:

Please check a couple of blog posts published a few years ago for more details and discussions:

https://blog.nettedautomation.com/2019/07/iec-61850-8-2-versus-iec-61850-8-1.html

https://blog.nettedautomation.com/search?q=mqtt

https://blog.nettedautomation.com/2019/10/iec-61850-for-monitoring-data-private.html

Unfortunately the Beck IPC com.tom Web PLCs with support of IEC 61850, ... disappeared ...

Please let me know your opinion ...

Siemens Industry to take over RuggedCom

The Siemens division Industry (not Energy!) announced yesterday (2012-01-30) that they agreed with RuggedCom to acquire Canadian network supplier RuggedCom Inc. The other day it was reported that Belden was trying to take over RuggedCom.

Click HERE for the Siemens press release from 2012-01-30.

It is quite interesting to see how long it took to make Ethernet an enjoyable solution:

Excerpt from the press release: “Siemens’ portfolio of industrial Ethernet networking components is enjoying above-average growth rates compared to the competition. Until now, the main emphasis of Siemens’ installed base in this segment has been in Europe. “RuggedCom’s portfolio would be an ideal addition to our range of industrial Ethernet communication products, improving our industrial-quality router and switch offering. In addition, the acquisition would improve our footprint in the North America and the Asia-Pacific region,” said Anton S. Huber, CEO of the Siemens Industry Automation Division. Huber also indicated that all of RuggedCom’s and Siemens’ product lines would be developed further in the next few years.”

What is meant by “competition” in the statement “industrial Ethernet networking components is enjoying above-average growth rates compared to the competition”? Is Ethernet competing with the “Profi”- and many other Fieldbusses … Profibus and ProfiNet … FF fieldbus …?

For me this deal indicates that the native Ethernet solution as provided by RuggedCom and used in IEC 61850 is the most “enjoyable” and successful network solution in the next 20 years or so! RuggedCom is (as Belden/Hirschmann) quite active in the IEC 61850 standardization.

When I worked for Siemens Industry in the early 90s, I recommended to use native Ethernet instead of fieldbusses … now we write 2012 – 20 years later.

Click HERE for the paper “Bridging MAP to Ethernet” [PDF, 720 KB, 1991]

Click HERE for the paper “Fieldbus standardization: Another way to go” [PDF, 720 KB, 1991].

Once Again: Is IEC 61850 another Protocol?

IEC 61850 and related standards like IEC 61400-25 offer very complex definitions that are intended to ease the life-cycle of the whole system: design, engineering, configuration, operation, maintenance, system extension, documentation, error diagnosis, ...
In my experience with protocols since 1982 (when I started working for Siemens) I have seen (too) many protocols coming and going. I guess I could list several hundred protocols including IEC 60870-5-10x, DNP3, Profibus FMS, Profibus DP, ...

Many experts (especially in the higher management and HR) have years of experience with one or several protocols - working with 600 baud or even 100 Mbit/s Ethernet based links. It happens quite often that those experts are promoted for higher management functions. Many of them have no experience with the approach of IEC 61850. But they often have to decide if, how and when the new technology will be used.

Because of the complexity, they may decide not to use it at all and even not trying to understand what it really could offer their engineers - at least as long as they are the persons in charge.

The real issue is (as Dee Hock, Founder of Visa put it): "The problem is never how to get new, innovative thoughts [IEC 61850] into someones mind, but how to get old ones out." One of these "old ones" is the opinion that IEC 61850 is something like DNP4 or IEC 60870-5-105 -- just another but more complex protocol (MMS, ISO 9506). This (old, too old, wrong) opinion has also a big impact on decisions, e.g., to get a green-light for attending an IEC 61850 training course. Managers and HR often have the opinion: Why do we need this comprehensive training (of 2, 3, 4, or 5 days) for just another protocol? Often the light stays at RED!
We could put it in future in a different way:

1. IEC 61850 Protocol Training -> 1/2 day
2. IEC 61850 Services (Client/Server, Publisher/Subscriber, Reporting, Control, Setting Groups, ...) -> 1 day
3. IEC 61850 Modeling and Models -> 1 day
4. IEC 61850 Engineering and Configuration -> 3 days 
5. How to use it for protection, SCADA, monitoring, power generation applications -> x days (depending on what application you have in mind).

If you don't understand what Models and SCL provide ... either take a course or stop discussing it.

IEC 61850 is not intended to replace any other protocol with MMS! In order to harvest the fruits of the application of IEC 61850, you have to look at any other topic than protocols.

But you have to be open to take a closer look at the issues listed under bullets 2 to 5.

You will not get an answer by just reading the standards ... take a course to get a reasonable understanding.

Be an ENGINEER - not just a boss or a leader.
Click HERE for a nice illustration at LinkedIn (or optionally HERE) to see the difference between old approaches and the engineers solution. IEC 61850 is a very big vehicle to carry a lot of loads - to make life easier.

I will post some example to show you the real benefits.

Smart Cars Under Attack- What Does it Mean for Power Systems?

We are quite often looking for smart things: cars, phones, power grids, ... expecting they make life easier or more comfortable. May be ... or may not be.
We have to understand and take into account that most of these smart things are under enormous pressure to become hacked.
Researchers have reported that "Smart car makers are faced with a potentially lethal hack that cannot be fixed with a conventional software security update. The hack is believed to affect all smart cars and could enable an attacker to turn off safety features, such as airbags, ABS brakes and power-steering or any of a vehicle’s computerised components connected to its controller area network (Can) bus. ... The hack is “currently indefensible by modern car security technology, and to completely resolve it would require broad, sweeping changes in standards and the ways in-vehicle
networks and devices are made,”"
Click HERE for the full report on computerweekly.
Click HERE for another detailed report also worth to read and FOLLOW.

Hm, that is no good news!

I hope that the power industry is using appropriate (security) standards to dramatically reduce the risk to hack devices used in power automation systems. One of them is IEC 62351. There are many other measures discussed on this block, e.g., the German BDEW Whitebook.
How many more wake-up calls do we need to change our ways how to secure energy delivery services? The more devices are brought into operation the more we need to care about security.

A lethal position of the management would be: "It could not happen to our systems - they are all safe. Really?

In the first years of open systems interconnection (OSI) ... early 1980s, I was quite unhappy with the Ethernet CSMA/CD method and the token bus solution. As a young engineer at Siemens here in Karlsruhe, I spent many hours and days of my free time (at home) to figure out how to improve the CSMA/CD to make the access deterministic - yes I found a solution! My colleagues and the management was supporting Tokenbus only ;-)

So, my patent was not used by Siemens ... but later I figured out that the CAN bus used the same algorithm I developed for my patent.

At that time almost nobody was expecting that years later people would intentionally hack media access protocols!! I remember one person complaining about OSI in the early 80s. He said (in German): "Wer offene Systeme haben will, der ist nicht ganz dicht!" This is not easily to be translated in English - I will try. "Offene Systeme" is "Open Systems". "Dicht" means "close" - and if someone is "nicht dicht" means: you are crazy. So: "If you want to have Open Systems - you must be crazy."

Click HERE to have a look at my patent (EP0110015).

I am really wondering that the old and for long time used protocols like CAN make that lethal trouble 30 years later! What will be next?

By the way, any Ethernet multicast shower in a subnetwork has the potential to crash a "smart" device. If the Ethernet controller has to filter out too many multicast messages it may stop to work.

Resume: Any system needs to be carefully designed, engineered and configured. Do you want to have a problem? No Problem!

The industry has to learn that a lot of changes in the way we automate today has to come!! That requires SMART People - and a lot more resources ... the costs of our living will definitely increase.

I question, if we have really made a lot of progress since the early 80s. Open Sytsems are too "open" ... we have to find ways to close the points where hacker could tap and "re-use" the messages in order to stop talking.

One Standard – multiple Terms for the same Thing

The Standard series IEC 61850 and IEC 61400-25 define hundreds of new terms for information models and communication models. Usually a term defined in one part and re-used in another part is the same (syntactically and semantically). In some cases you will find different terms for the same “meaning”.

Here is one example to explain what I mean:

The Standard part IEC 61850-7-2 (ACSI) defines in clause 12.3.3.3:

TrgOp [0..2] – trigger option

The attribute TrgOp of type TriggerConditions shall define the trigger conditions (associated to a data attribute of a data object) that may cause a report to be sent or a log entry to be stored into a log.

Three values are defined to be used inside the data object:

dchg data-change A report or a log entry shall be generated due to a change of the value of the associated data attribute

qchg quality-change A report or a log entry shall be generated due to a change of the value of the associated quality data attribute q

dupd data value update A report or a log entry shall be generated due to updating the value of a data attribute. An updated value may have the same value as the old
value. An example is freezing the value of a freezable data attribute updating the value of another data attribute, which could lead to the same value it already has.

The trigger conditions integrity and general-interrogation of the TriggerConditions type are used independent of instances of a data object.

The service parameter IntegrityPeriod is mapped to intgPd:

17.2.2.12 IntgPd – integrity period

IntgPd shall indicate the period in milliseconds used for generating an integrity report.

So far so good – even we have already three terms:

integrity, IntegrityPeriod, IntgPd, or integrity period.

What does part 6 (SCL) define?

<xs:complexType name="tTrgOps">
   …
   <xs:attribute name="period" type="xs:boolean" use="optional" default="false"/>

and for the value attribute of “period”: intgPd="2000" in the report configuration element.

So, we find six terms that mean more or less the same thing … you have to understand what they mean and when to use one or the other!

When it comes to IED Configuration Tools (ICT), you may have to learn new terms again:

Here the SCL attribute “period” is set to true, if the checkbox for “Included in Integrity/Poll” is set.

By the way, these terms describe something quite easy: Push all (!) values of a DataSet every n milliseconds. Without a request from the client. In addition to the cyclic push you may configure the server to report the value of a single signal after it has changed (data change)):

You want to learn how to use the standard? We offer training courses that help you to apply the standards in your daily business! It is more convenient to attend a training than to read all the standards … we have the long-term experience that we would like to share with you.

Is IEC 61850 Plug&Play or like DNP4.0 or IEC 60870-5-105?

There are many different expectations I heard from protection and control experts all over. Some people guess that IEC 61850 provides Plug&Play capabilities – meaning: Utilities just purchase IEC 61850 IEDs and (all in a sudden) their protection and control systems are up and running! There is a group of other people that expects that IEC 61850 is just another protocol – a bit more than today’s solutions … something like “DNP4.0” or “IEC 60870-5-105” [of course DNP4.0 and 105 are not real!].

IEC 61850 is much more than DNP3.0 and IEC 60870-5-104, and it does NOT provide Plug&Play. Building substation protection and control systems requires to understand the applications (the many protection and protection related requirements) and to find a way how to apply IEC 61850 compliant IEDs and tools to solve their many needs.

IEC 61850 is a suite of tools that can be used to solve application needs. How to use the tools and when, is NOT defined in the standard! Utilities have to find their (step by step) way to get started with IEC 61850 based solutions. It is important to get started – don’t wait until IEC 61850 solves all your needs and problems. This will never happen!

Some US experts have discussed in 2005 or early 2006 what IEC 61850 provides and what needs to be done to apply the standard and standard based solutions. They show that IEC 61850 has an impact on many aspects in system design and deployment.

IEC 61850
A Practical Application Primer for Protection Engineers
Bogdan Kasztenny, James Whatley, Eric A. Udren, John Burger, Dale Finney, Mark Adamiak

Click HERE for the 43 page paper – worth to read.

My hope is that readers of the paper (hopefully readers from the utilities – or students finishing their education soon) understand that IEC 61850 requires utility people that are well educated in IEC 61850 – in order to understand what the big vendors have commissioned and how to use the various features of the new design.

Today I received an email from one the international biggest transmission utilities asking for help in better understanding what is needed and what has been commissioned:

“Karlheinz, …. As you probably know, there are more and more digital substations in XXX, provided by XXX and XXX for the time being. Even if our contracts does not specify explicitly the use of 61850, they are based on this standard. Today, these substations can be viewed as black boxes, without really taking into consideration the advantages of new digital technologies. …”

One of the crucial needs is: MORE EDUCATION FOR UTILITY EXPERTS!! I have met many utility people that were responsible for the substations based on IEC 61850 – but DID NOT any clue how to use IEC 61850 build in functions.

IEC 61850 has a crucial impact on the WHOLE system and the engineers that build systems.

Finally, SCADA applications (to get status changes, limit violations, measurements, statistical information, historical information, …) can apply IEC 61850 right away with commercially available Off-The-Shelf (COTS) solutions like the well appreciated Windows DLL for IEC 61850 (applicable for servers, clients, publishers, and subscribers).

Click HERE for a Windows DLL evaluation kit with an C# application example including source code of the client and server applications (that use the DLL).

IEC 61850 For Monitoring Data - Private or Standard?

One of the most crucial issues in the management of energy systems is: HOW TO share or exchange useful information generated by a myriad of sensors and applications needed by hundreds of applications?

Lets assume that lakes of information are generated every second. Usually this information is stored in silos of vendors specific solutions and communicated using one or more vendor specific communication solutions ... as shown in the following sketch drawn by our grandson Jan Oliver:



The expectations to apply IEC 61850 are high! BUT quite often vendors argue, that it is easier to use their private solutions - faster and saves time and costs! This may be true for the first phase of a project - but in the long run and in the view of the life time cost it may be completely opposite.

Three experts from Vattenfall DSO (Sweden; Vincent GLINIEWICZ, David EROL Anders JOHNSSON) have reported at the CIRED conference 2019-06 in Madrid (Spain) from an implementation of a pilot project using IEC 61850 and CIM  with the title:

LEVERAGING INDUSTRY STANDARDS TO BUILD AN ARCHITECTURE FOR ASSET MANAGEMENT AND PREDICTIVE MAINTENANCE

Excerpt from the paper:

"... However the data unfortunately currently often remain unused and unshared outside of the substation or specific silos for various reasons, some technical (e.g. cyber security, system incompatibility), some and organizational (e.g. vendor lock-in, siloed applications and organizations).
Additionally, with an increasing number of use cases requiring access to information, there is a growing number of information flows needed not only between data sources and central level applications but also between these central level applications. Without an IT architecture that allows reuse of information flows, there are legitimate concerns that the opportunities that digitalization promises might be delayed and costly or even worse, not be achievable.
As a result, Vattenfall Eldistribution sees a standard based integration approach as a cost-effective approach that seems to offer in the long run low integration costs and more importantly a greater flexibility, going from supplier specific integrations to a more generic approach. ...

We would also like to highlight some of the deviations from the standards that were observed during this pilot:

The pilot made use of a REST API towards the real time data historian (RTDH in fig. 2), although there was no mention of REST in the 61968-100 standard. One could however expect, given the increasing popularity and use of RESTful services in most industries, that the standard will soon follow and that the mention will be added in a further edition on the standard.
The gateway used in the pilot was a prototype base on a technical report (IEC TR 61850-90-2) [Using IEC 61850 for communication between substations and control centres] which is not yet a standard. This might explain why there doesn’t seem yet to be a complete and robust 61850-90-2 compliant product on offer in the market. Another alternative considered for the pilot gateway was the use of IEC 61850/MMS towards the substation and the use of web services (either RESTful+ JSON or SOAP) to communicate northbound instead of the IEC 61850/MMS used in the pilot. SOA has indeed a robust and well developed architecture for distributed computing, and this should be leveraged. There however did not seem to be any products available on the market. This alternative will be explored in a coming pilot. ..."

The paper concludes:

"Although the pilot was made for a primary substation, the widespread use of the IEC 61850 standards series make the results of this pilot not only applicable for primary substations, but potentially also secondary substations and microgrid.
Following the successful pilot, the next step is to look at how to fully implement and verify the concepts in a real substation and to secure production grade components where prototypes have been used as well as test the architecture through other smart grid use cases."

Click HERE for the full paper.

I have run an UCA/IEC 61850 pilot project with Anders Johnsson some 20 years (!) ago:

Two reports out of this pilot project and other discussions have been published in 2002:

Wind Power Communication
Verification report and recommendation

Click HERE for the Report.

Wind Power Communication - Design & Implementation 
of Test Environment for IEC61850/UCA2

Click HERE for the Report.

Enjoy the reports.

By the way: It took some 20 years to understand that the mapping of IEC 61850 models and communication protocols to MMS (ISO 9506) should be extended by a much easier and simpler mapping to JSON and, e.g., MQTT or http ...

It is not too late for such an additional standardized mapping ... e.g., as IEC 61850-8-3.

It may take another 10 years before this becomes true! Hope it will happen a bit earlier!

Further reading on the subject see discussion of IEC 61850-8-1 versus 8-2 (by 2024-02-25: 4074 visits of the post since July 2019).

Other people have similar ideas and published the following paper:

International Electronical Committee (IEC) 61850
Mapping with Constrained Application Protocol
(CoAP) in Smart Grids Based European
Telecommunications Standard Institute
Machine-to-Machine (M2M) Environment

The "Beck-Bone" for Smart Grids Demonstrated at IEEE PES GM in Minneapolis

BECK IPC (Pohlheim, Germany), SystemCorp (Perth, Australia) and NettedAutomation (Karlsruhe, Germany) successfully demonstrated the "Beck-Bone" for Smart Grids at the IEEE PES GA in Minneapolis (MN, USA):
The IEC61850@CHIP.

More than 2,500 experts attended the IEEE Power & Energy Societies General Meeting in Minneapolis (MN, USA) form 26 to 29 July 2010. One of the highlights of the Power System Communications Committee's Event was the demonstration of a breakthrough implementation of IEC 61850 (IEC 61400-25) on a Chip. Detlef Raddatz (SystemCorp) runs a last test prior to the big show:

 

Detlef demonstrates the benefits of the IEC 61850 software running on different HW platforms (all using the same Chip): Development Kit DK61 (middle of photo), ruggetized I/O modules (left), COM.TOM module (right):

The Development Kit DK61 comes with IEC 61850 (61400-25) stack software, an easy to use API with 13 functions only, with C/C++ and IEC 61131-3 programming languages, FTP, Telnet, TCP/IP, IPSec, sample C code and sample exe files that run immediately, and comprehensive documentation.

Click HERE for more details of the DK61.
Click HERE to download the order form to get the special fair offer of US$ 1.250.

The stack software and sample code (source and exe) have been introduced in Minneapolis as DLL demos (client, server, publisher, and subscriber). The DLLs run for 6 months fully functional for up to 50 signals/points. The demo also contains the fully functional SCL designer to model up to 50 signals/points. The server runs the same model as provided with the DK61. You may use the DLLs for any other application you build around them. The given sample code runs on one PC (local host) and two PCs. The DLLs run under Windows - while the Beck Chip runs a very powerful real-time operation system (RTOS) for real-time applications.

Click HERE to download the DLLs to run under Windows (available end of August 2010; the availability will be announced in a new blog posting as soon as it is available).

During the many technical discussions experts had questions about the platform and functions. People had been quite surprised when they understood the performance of such a simple and small platform.

 

The Buffet offered a variety of food and beverages ... including Beck's Beer and Beck "Chips". The German brewery Beck and Beck IPC (the chip manufacturer) are not linked.

Professor Dr. John Newbury (The Open University, Manchester, GB) was quite happy to see the results of 15 years of standardization work in IEC TC 57 (WG 10, WG17, WG 18) and TC 88 PT 25 (IEC 61400-25, Wind Power) on such a small but powerful platform:

What are the steps towards a the "Beck-Bone" for Smart Grids and many other applications?

1. Many experts start with the Development Kit DK61 to do hands-on exercises using the provided software examples to get a good understanding of the IEC 61850 models and services. One of the big vendors of controllers reported the other day that they we able to implement their network interconnection for connecting PV systems to the power grid within 2 weeks !! The grid connection is completely modeled in IEC 61850.
   This is the easiest way to get your data communicated with IEC 61850 (IEC 61400-25). Another approach could be to start with DLLs on a PC and then use the DK61 for real-time requirements.
2. In case of implementing interfaces, e.g., for pilot projects, it is convenient to use one of the many ready to go COM.TOM modules:
   
3. After successful pilot projects it is recommended to use one or the other Chip in your specific hardware:
   
4. Other components hardened for higher EMC requirements are offered by SystemCorp: RTUs, Gateways, Protocol converter, ...
   

All these and other components implement IEC 61850 on the Beck Chip. The IEC 61850 stack software (developed by SystemCorp) runs on many other platforms:

Click HERE to visit the SystemCorp website (Perth, WA, Australia).

Huge KIT Energy Lab 2.0 - Relies on IEC 61850

The KIT (Karlsruher Institut für Technologie) in my hometown Karlsruhe/Germany is deeply involved in several projects related to the Energiewende. One of the crucial components is the "Energy Lab 2.0".

In "A Concept for the Control, Monitoring and Visualization Center in Energy Lab 2.0" the authors Clemens Düpmeier, Veit Hagenmeyer, Ralf Mikut, and Karl-Uwe Stucky present an interesting concept.

Click HERE for a 16 page presentation presented in November 2015.

The research focuses on the APPLICATION of Control, Monitoring, and Visualization of various aspects of energy systems (gas, electricity, heat) - not just electrical systems.

IEC 61850 is THE solution for the process instrumentation - share process information in a standardized way.

These people have understood that the focus is on applications rather than on protocols ...
The 14 Layer Cake I had after a nice dinner in Jakarta shows that the automation of the energy systems of the future is more than "just another protocol" ... applications based on standard protocols are the crucial aspects:



Hm, the cake was very delicious.

How many employees will drive an electric vehicle?

A German manager recently said that 500 employees of his company drive by car to the company every workday. He expects that in the future 250 will use electric cars and will charge their cars within the first hour after they arrived. The company would need 10 times more power than today!
Ok! Hm!?
What do you think about these assumptions? 250 EVs charging in the first hour!?
As an engineer I am wondering that experts come up with such examples. First of all, I do not expect that 50 per cent of the car owners will buy an electric car in the next years. Even if they would do, why do 250 car drivers want to charge at the companies car park in the morning when they arrive?
He concludes that "we engineers have not yet thought through to the end".
I guess a lot of engineers have thought through to the end - but not many engineers or politicians are listening!

Click HERE for the report "Netzstabilität braucht Digitalisierung und Automatisierung" in the vdi nachrichten (German).

These discussions remind me of the situation in the early 80s when we had the discussion on CSMA/CD (Ethernet, IEEE 802.3) versus Token Passing (IEEE 802.4). Under the assumption that we have a shower of messages to be sent by all attached devices at the same time, we found that Ethernet could not efficiently manage the communication due to many collisions. Token Passing was understood to manage such a situation very well. Ok.
Another assumption, high load from one device only, could easily be managed by CSMA/CD - but Token Passing would end up in very low throughput ... many other assumptions could be made.
So, what is the realistic assumption for communication? Nobody knows - it all depends.
Finally Switched Ethernet (a major new development) solved the collision problem ... and Token Passing more or less became obsolete in the automation world.

In the energy domain we need first to find the future new mix of power generation and how to store, transmit, distribute, and use the power - then we can think about automation and communication. The most crucial issue may be: Who is paying for all the changes?

By the way: We (many engineers) know how to communicate: IEC 61850 is one of the most crucial solution ... and how (not yet what) to automate.

Wind and Solar Power – Could have helped to prevent the Indian Power Outage this week

It was questioned if wind and solar power could have been used as a redundant power source in this weeks power outage in India. Yes it could – indirectly.

Wind and Solar power could help to keep the water in the big reservoirs in the mountains. Each MWh from wind turbines or PV systems would keep the “redundant” hydro energy in the storage reservoirs. In case of a shortage in the grid this “redundant” hydro power could be used to stabilize the grid. Especially this year in India and north of India the water levels in the dams are very low … it would be a benefit not to “burn” the available hydro energy during the day when you could use the wind or solar power. There is one issue with not “burning” hydro power: usually you are paid by the amount of energy you put into the grid – not by keeping it for days or weeks. Making money and providing reliable energy supply are two different aspects.

IEEE Spectrum: Lack of Rain a Leading Cause of Indian Grid Collapse

In Europe there is work going on, to use the (surplus) wind power in northern Germany and pump water in the dams in Norway and use it as a huge hydro power storage … and there is another very interesting storage possibility for wind and solar power: Wind Gas or Solar Gas!

What is that? Never heard about it?

http://blog.iec61850.com/2012/06/two-mw-wind-to-gas-converter-build-for.html

I would highly appreciate if I could produce my own gas, store it and use it in winter time (Sothern Germany).

It is just a little bit too expensive … but the technology is available:

http://www.fronius.com/cps/rde/xchg/SID-7EA7CFA3-6E3959B6/fronius_international/hs.xsl/83_18098_ENG_HTML.htm

These ideas and technologies will help to convert the electrical grid into a Smart(er) Grid. Engineers have developed great solutions … it is up to the decision makers to let them do their job!

By the way, Smart Grids have been invented by smart engineers since the 19^th century:

http://blog.iec61850.com/2012/03/smart-grids-19th-century-invention.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)