Email This Author

Comment On Article

About The Author

More Articles By This Author

Interested in this topic? Need more information? Energy Central has created a complete information service focused only on Substations. There is no better way to stay informed. Get more information on Substations today!

IEC-61850 is a high level object-oriented protocol that defines a vendor independent communication infrastructure allowing seamless IEDs integration. The protocol had been developed by the efforts of two groups: EPRI/IEEE, and Technical Committee 57 of the IEC. The results of their efforts culminated into a powerful object-oriented protocol that became a standard in Substation Automation. The protocol greatly simplifies substation automation architecture, allows rapid project development and has many other advantages. Discussing the protocol itself goes beyond the goals of this article.

The Decision to Develop IEC-61850 OPC

Substations automation using IEC-61850 has become increasingly popular in recent years. Despite the full acceptance of IEC-61850 among hardware manufacturers, we had a perception that software support lagged far behind. We were receiving several calls a day from our customers, asking about IEC-61850 OPC software and whether we had a version that could solve the laundry list of problems they were experiencing. So, in mid- summer 2007 we began our project. The first thing we needed was protocol documentation.

Buying documentation was the easiest part of the development process, although not without problems. In attempts to optimize our engineering and architectural time and to estimate the final price tag of our product we had to figure out what exact documents we needed to complete the project. So, we figured out that we need only two-thirds of the available documents.

Right from the beginning we found that it was very difficult to create a complete picture of the protocol without reading and understanding all the documents. The official IEC-61850 documentation contains an enormous amount of information dispersed among many documents. Very often descriptions of the same things in different parts of documentation are not very consistent. Later we had to buy almost all the documents.

Because we had such aggressive plans we established multiple milestones, one of which was to receive the first message from the IEC-61850 enabled relay two weeks after starting the project. Our engineering team paid special attention to this first milestone as from their experience this step was like a proof of concept, and showed that we had set the right expectations. If we are able to establish a connection and start receiving messages it usually takes only a few extra steps to finish the product: to check and, if necessary, optimize the performance; implement a complete set of requests and responses; and proceed with testing. So, receiving a first message was planned as a major event. It was not like a celebration of winning a multi-million contract but nevertheless the management was invited to see the results. People gathered in the conference room, relay was connected, Server and Console launched, host and port were specified, … and alas! … no message received. Engineers tried to do last-minute debugging and code fixing but the message did not come through, neither that night nor one week later. The first message did eventually come through, but it happened two weeks later than we had originally planned.

Discoveries Made

After the “demonstration” engineers had to answer the tough questions of “what,” “when,” and “how?”: what happened, when can we expect to see the first message, and how is this going to affect the planned release date? This is the moment in a software engineer’s life when he or she realizes the toughness of the profession.

The problem with our project was that our engineers overlooked the whole communication protocol layer. It took several days of reading, drawing, testing and arguing to figure it out. It was like digging layer after layer: after the first reading of the documentation you see that much, after the second you see more and after the third you believe you understand. When it came time to redefine the deadlines the engineering feedback was not very promising. They asked for at least two extra weeks to get the first message through and two extra months to finish development. Testing time had also been extended by one month.

The engineers fulfilled their promise to meet the new deadline, and we saw the first message in two weeks. Subsequent steps went smoothly without major surprises, optimization phase took one more week and coding all other requests and events took another three weeks. With all the necessary testing, we were able to release the IEC-61850 OPC Server even earlier than planned. The surprises with the IEC- 61850 implementation were quite unusual, so our development team decided to share this experience with others and provide some technical and planning recommendations.

Technical Recommendations

Many concepts of IEC-61850 are surprisingly unusual. The IEC-61850 protocol family resides on top of multiple underlying communication protocols, which are described in different subsets of documents. It takes a significant amount of time for one person to read all documents and to understand and keep the whole concept in his or her head. The common way to overcome such a difficulty would be to spread reading, understanding and writing the pieces of the code among a few engineers. However, the inconsistency of the documentation effectively precludes this approach. If the engineering department does split the work, there is a good chance that those pieces will not fit together and will require a long testing-debugging and fixing cycle. The best way to resolve this issue is to allocate a significant amount of time for a design phase, so that a chief architect can understand the entire concept.

The engineering team should know programming well beyond working with well-defined stacks and libraries. They should have skills to understand protocol development techniques. Implementing of its own protocol stack is also challenging because the developed code will be a foundation upon which the rest of the software will be developed. Therefore the code should be robust and well optimized. Any performance bottleneck, inefficiency or instability will affect the rest of the code. To be able to do so one needs to have a staff of developers who has enough skills to understand and locate potential bottlenecks, be skilled in code optimization and be able to write very reliable code. People with those skills are difficult to find, and without them the product has a high probability of failing.

This might be the reason why just a few implementations of IEC 61850 protocol exist so far. We were looking for available IEC-61850 stack implementations when we were doing make-versus-buy analysis. The examples we usually saw implement only a subset of functionality, lack runtime diagnostic and have drawbacks and bugs, causing serious issues.

Planning Recommendations

First, make sure to plan frequent milestones. It may sound obvious, but many project managers ignore such planning and find problems too late in a release cycle as a result. In our case, by setting definite deadlines we were able to detect potential problems at a very early stage of development and to avoid frustrating our customers with too many delays. Our use of milestones helped us release the product one month earlier than our adjusted plan.

Second, have a lower level design in place before planning. Ideally somebody who is familiar with IEC-61850 internals can review the design.

The difficulties of IEC-61850 stack implementation described in this article do not diminish the value of the protocol itself. The protocol is a significant step in communication unification and has a great future.

We know you have something to say!

Contribute Today!

Do you agree or disagree with this article? Send in your own article.