by Christoph Brunner, it4power, Switzerland
I believe that we have been already implementing eIoT longtime before it was known as that, and we have the base ingredients available for discussions.
When reading the title, you are probably asking yourself, what does that title mean. Or if you know that IoT means the Internet of Things and IOP denominates the interoperability testing organized by the UCA international users group, you may wonder why I put those two completely different topics together in the title of my column?
Well – there is no particular linkage between the two topics, other than that I was confronted with both of them during the last few weeks.
The IEC 61850 IOP 2019 took place this year in Charlotte, NC, USA at the EPRI site. It was the fifth such event; after New Orleans in 2017 the second one in the US. At the IOP, we always try to test the latest features of the standard. Thus, vendors do not participate with conformance tested devices and tools – they participate with prototypes implementing the new features. This has two benefits:
- On one side, the vendors can test their latest versions of the products regarding interoperability
- On the other side, it allows us to identify gaps and inconsistencies in the standard specifications and thus helps to improve the quality of the standard
Since the IOP 2017 we have tested interoperability in what we call an integrated application. Basically, emulating a substation and allocating the different devices based on their functionality. Based on the experience from 2017, we defined the device allocation and requested the ICD files well ahead. The icd files were checked with various tools and eventually sent back to the vendor for correction.
The system design was done with two system configuration tools. We also prepared a test plan – something that was missing in 2017.
The application we modeled not only allowed many GOOSE messages; we also had many vendors participating with merging units and with protection devices supporting sampled value interface.
This year, we could configure the first IEDs for the integrated application during the first day. By Wednesday more or less all IEDs were configured, and on Friday we could successfully run a test of the integrated application, including the use of test mode and simulation.
Unfortunately, most of the IEDs and associated tools had not yet implemented the Edition 2.1 of part 6. Therefore, we experienced similar problems we already discovered at prior IOPs (and which led to the enhancements in part 6). Every vendor had its own method in where GOOSE message and signal subscription should be configured, most of them were not compliant with Edition 2.1 of the part 6. Improvements regarding GOOSE configuration was one of the most important enhancements of Edition 2.1 – unfortunately it is not yet available in most vendor implementations.
Overall, the quality of the icd files was low – this is a result from the fact that conformance testing has been too long ignored, that the IED, its icd file and its tools are one entity that shall be tested together.
In the past, the focus of conformance testing was on communication. For the future, the test procedures of UCA need significant improvements to add value. And I strongly recommend users to request the implementation of the latest versions of the standard from their suppliers.
Now to the IoT. The electric Internet of Things (eIoT) has now replaced SmartGrid as a buzzword. For the plenary meeting of IEC TC57 in Shanghai last October, China suggested that TC57 shall address the electric Internet of Things in its work.
What is IoT? According to the definitions of IoT, every “Thing” is connected over the Internet and can exchange information with others. What is a “Thing” in the electrical network? That can be a switch or a transformer, a recloser, in principle any equipment in the electrical network. But it can as well be a fridge as a controllable load, or a power pole, a temperature sensor or a humidity sensor.
The “Thing” then needs a communication interface with a protocol supporting peer-to-peer communication and it should be plug and play. And finally, although often not mentioned, it needs in my opinion, a semantic data model.
Well – for me all that sounds a lot like IEC 61850. I am definitely of the opinion that we have already been implementing eIoT longtime before it was known as that. With GOOSE and Sampled values we have peer to peer communications that support sensors as well. With the concept of the ACSI, we can integrate any other protocol, and IoT protocols as well. The data model with the logical nodes and the possibility to extend it, supports modeling the semantic of any “Thing.” And the communication services support self-description and with that plug and play.
Thus, I believe it is a good idea to address eIoT in TC57, as we already have the base ingredients available.
Biography
Christoph Brunner is the President of his own independent consulting company it4power LLC based in Switzerland. He has over 25 years of experience with knowledge across several areas within the Utility Industry and of technologies from the Automation Industry. He has worked as a project manager at ABB Switzerland Ltd in the area of Power Technology Products in Zurich / Switzerland where he was responsible for the process close communication architecture of the automation system. He is Convener of WG 10 of the IEC TC57 and is a member of WG 17, 18 and 19 of IEC TC57. He is senior member of IEEE-PES and IEEE-SA. He is an IEEE Fellow and is active in several working groups of the IEEE-PSRC and a member of the PSRC main committee and the subcommittee H. He is advisor to the board of the UCA international users group.
