Saturday, August 22, 2009

Interoperability in the context of IEC 61850

There are many efforts underway to define or extend standards that allow or support Interoperability between devices in the electric power delivery system. IEC 61850 is one of the crucial standards that is understood as to meet basic requirements.

According to the "EICTA White Paper on Standardization and Interoperability, Brussels, November, 2006 (page 4)" Interoperability is defined as follows:

“The capability of two or more networks, systems, devices, applications, or components to exchange information between them and to use the information so exchanged.”

What does this all mean for the application of IEC 61850? Currently there are some problems with the interoperability of real devices implementing one or the other option of IEC 61850. That is the challenge: Which option do the devices use that are intended to be interoperable?

We have to differentiate interoperability on different levels: physical, syntactical, services, devices, … functions. In the following we will briefly focus on services and devices [Note: This discussion just points to the general issue of options; details on interoperability issues are presented and discussed during the seminars of NettedAutomation GmbH (Karlsruhe/Germany)].

The following slide summarizes some option of what Interoperability could mean for a simple use case. The Purpose of the use case is:
Monitor the Temperature (Tmp) and figure out when the Tmp exceeds the Limit (Lim). There are two devices involved (Client and Server). Depending on the functional distribution of the monitoring function (located in the client or in the server) we can use one or the other Service of IEC 61850. In the case of Services A and B we assume that the purpose is to implement the monitoring function in the client. In the other two cases (C and D) we assume that the monitoring function is provided by the device that acts as server.

Interoperaility_2009-08-20

The four services (associated with the functional distribution) are quite different. Once the "user" (usually the system integrator) of the client and  the "user" of the server HAVE DECIDED WHICH APPROACH (A, B, C, or D) to use then we could talk about interoperability. IEC 61850 DOES NOT constrain which approach to use. IEC 61850 is scalable - that means YOU HAVE TO make decisions how to scale! Which option to use!

The IEC 61850 services do not constrain the behavior of an IEC 61850 client application process, except with respect to valid sequences of service primitives. Therefore a model of the IEC 61850 client application process is not (!) provided in the current standard.

If the two "users" decide to use the option with Service A then we could define, what is required to make the client and server interoperable. This is defined in IEC 61850 for all approaches shown in the figure.

Challenges with regard to interoperability are here: The "users" of both devices DO NOT define the exact approach (to use an approach with Service A or B, C,or D). Just to expect that the vendors have implemented ALL approaches is dangerous: Usually the vendors implement the mandatory (M) requirements - which could also be translated to M=Minimum! Two devices conformant with IEC 61850(with a Certificate) may or may not interoperate! Depending on the functional distribution and the services provided and used.

Non-Interoperability could have many reasons:

1. Client and server might implement only a subset of the full specification. In some cases, there may be a mismatch in what features are supported, where one system sends a message that the other cannot process.

2. The IEC 61850 specification makes certain things optional. If one implementation assumes that specific information will exist on messages it receives, it may not interoperate with another implementation that chooses not to send that information.

3. Two implementers may interpret parts of the standard, where the language of the specification is ambiguous.

4. Finally, implementers may simply have bugs in their implementation that that do not show up during standalone testing. Such bugs may also contribute to interoperability problems when two different implementations attempt to hook together.

To make devices interoperable requires (among other requirements) that the "users" of two devices specify exactly the distribution of the (application) functionality and which service to use for that functionality!

This specification (and the discussion of the involved people) is mainly outside of the standardization work. Some hints on the modeling approach (not that much on the use of services) will be given in new documents to be published by IEC, e.g., IEC 61850-7-510: Hydroelectric power plants – Modeling concepts and guidelines. This Technical Report is intended to provide explanations on how to use the Logical Nodes defined in IEC 61850-7-410 as well as other documents in the IEC 61850 series to model complex control functions in power plants.

Example of working draft of IEC 61850-7-510 (2009-08) - Excitation function:

image

The document will provide general use cases of the models defined in IEV 61850-7-410.

Sustainable Interoperability of devices is a crucial challenge in the domain of Power Automation systems.

2 comments:

Gigi said...

First of all compliments for this blog, it's real a reference for me.
I think that one of the problem related to Smart Grid implementation is the anti-islanding protection. Do you think that some concept discussed in 61850-90 (like goose in tunnel) could be a way to implement it ?
Thanks

Karlheinz Schwarz said...

The anti-islanding protection is likely to be discussed and solved in the next edition of part IEC 61850-7-420:
Communication networks and systems for power utility automation –
Part 7-420: Basic communication structure – Distributed energy resources logical nodes