by Fred Steinhauser, OMICRON electronics GmbH, Austria
Pilot projects are a great thing. We can try out new things with managed expectations and under relaxed conditions. If it is not a disguised business as usual project …
Pilot projects are wonderful challenges for engineers. We are allowed to go for something new. The risks involved are accepted by all stakeholders, and resources are assigned to deal with them. The efforts to evaluate solutions are foreseen, we can check out novel concepts and learn. The options and designs tested in the pilot project shall be the foundation for the business as usual projects to come afterwards. In any way, a pilot project needs to explore some unchartered ground to deserve this title.
The management proudly announces the pilot project to underline its innovative leadership. And the engineers not only enjoy mastering the technical challenges, but also hope for an opportunity to publish papers or give presentations about their achievements. These publications are, by the way, not a matter of personal pride but a kind of documentation and the necessary communication to the community for also learning from the project and accumulating best practice.
So far so good. But not in all cases where pilot projects are named as such, the preconditions are as great as just described above. There are many ways where the shiny label is used for projects that are actually restricted in several ways. This may not matter for those who announce it, but definitely for those who shall implement it. It may put the engineers in a lose-lose situation.
When it comes to pilot projects to explore the applicability of IEC 61850, we often hear the announcement ending with a phrase such as: “… and we decided to do it with <some vendor>.” At that moment you already know that this will be no real pilot project. Because one key property of IEC 61850 is interoperability, and this is for sure not going to be explored in a project implemented with a single vendor’s products.
You are not going to evaluate much under such preconditions. Since you already have decided to use this one vendor’s products, you are just going to experience the specific abilities of these products. And instead of assessing a choice of products and maybe rejecting those that do not serve your needs, your experience will be how to create workarounds for possible shortcomings. The vendor will also not be motivated to fix anything in a product that you have already decided to use, this is commercially not viable.
To maintain the claim of exploring interoperability, some projects are set up with selecting two vendors, which is obviously the absolute minimum to approach this goal. Very seldom we see more than two vendors’ products scrutinized in an evaluation phase.
There might be several reasons to proceed this way. Although the management wants to showcase innovation, it may not grant the proper environment and enough funding. The implementors must step on new ground, without the possibility to explore it thoroughly.
Thus, engineers often need to play a safer bet. And then it is a reasonable choice to lean towards a vendor that has a record of serving them well. They can trust that the vendor will at least deliver a working system, no matter how much or little innovation or interoperability is in it.
So, there are comprehensible reasons that undermine the idealistic goals of projects that claim to push the limits, but then please do not call such setups pilot projects.
At least give us the documentation afterwards, so we can learn from it and improve the state of art. If you keep it secret, we can draw our conclusions as well …
Biography:
Fred Steinhauser studied Electrical Engineering at the Vienna University of Technology, where he obtained his diploma in 1986 and received a Dr. of Technical Sciences in 1991. He joined OMICRON and worked on several aspects of testing power system protection. Since 2000 he worked as a product manager with a focus on power utility communication. Since 2014 he is active within the Power Utility Communication business of OMICRON, focusing on Digital Substations and serving as an IEC 61850 expert. Fred is a member of WG10 in the TC57 of the IEC and contributes to IEC 61850. He is one of the main authors of the UCA Implementation Guideline for Sampled Values (9-2LE). Within TC95, he contributes to IEC 61850 related topics. As a member of CIGRÉ he is active within the scope of SC D2 and SC B5. He also contributed to the synchrophasor standards IEEE C37.118.1 and IEEE C37.118.2.
