Self Description
Trials and Tribulations

Integrated Protection and Interoperability Technology Drives the Requirements

In 1994 and 1995 a group of engineers worked together to define the requirements for substation integrated protection, control and data acquisition. Sponsored by the Electric Power Research Institute (EPRI), these experts focused their attention on two keywords: 'integrated' and 'interoperability'.

The emphasis on ‘integrated’ meant the integration of protection and SCADA over one substation local area network using digital communications between intelligent electronic devices (IEDs). ‘Interoperability’ meant the ability to exchange information between IEDs using either a common protocol or cooperative protocols. Cooperative protocols were included because, in addition to the communication between IEDs, communication between substations and between the substation and remote Energy Management System (EMS) and Distribution Management System (DMS) control centers were included.

These communication requirements were documented in an EPRI report, commonly referred to as RP3599. Over 600 members of the utility, vendor and consultant community in North America and Europe reviewed these requirements and submitted recommendations for improved language. With this review completed, the work has been submitted to several international standards making groups, supported by their study committees, to develop international standards.

The Trial and Tribulation of Self Description

One additional requirement of RP3599, 'Self-description' has, in my opinion, resulted in a very divisive situation between IED vendors. Divisive in the sense that device vendors (those who manufacture multifunction relays) have become frustrated by the slow progress in obtaining agreement on how this should be implemented. First, let’s set the record straight as to how RP3599 states the requirement.

"Optionally, an IED should be able to describe its object model in some detail, including classes, attributes, services, data types, associations, and inheritance hierarchy, for example. Self-description has the potential to simplify several processes, including integration of legacy devices, evolution of IED standards, and system setup procedures. Ultimately, standards for self-description will replace IED object models as standards, because standards for IED objects will evolve as device capabilities are extended, the standards for device self-description are expected to be stable."

RP3599 states that self-description is a desirable requirement, not a mandatory requirement. Although not mandatory, laboratory tests have shown that integrated protection needs automatic IED-to-IED exchange of data without an intermediate device acting as a gateway. A gateway adds too much time. That is, the receiving IED must understand the semantics of the data sent from the sending IED, which for integrated protection is the protection relay

If the enabling communication protocol includes the facility for the sending IED to invoke an operation of the receiving IED, the requirement is easily satisfied. For example, if the protection relay needs to trip the breaker, then the message to invoke ‘trip’ must be understood by the relay IED manufactured by any vendor. Providing such a remote procedure call to invoke ‘trip’ isn’t difficult, so what is the problem?

If the vendor community selects a communication protocol such as MMS (ISO 9506) that doesn’t implement remote procedure calls (or its equivalent), they will have trouble. For example, MMS requires trip to be initiated by writing to a named variable; the semantics of that variable must be defined. One variable for one operation should not be a big deal. The problem is that there are many variables and many operations needed to implement all substation operations. The community now must come to agreement on all combinations – this has proven to be difficult and very expensive.

To make matters worse, EPRI decided to sponsor an approach to enumerate all data objects for substation and feeder equipment (called GOMSFE – Generic Object Model for Substation and Feeder Equipment). Not only were the variables and data structures for high-speed automatic operations to be enumerated, but all configuration parameters and operating parameters were included in EPRI’s initiative. Substation engineers and protection engineers have tried in past IEEE committees to develop a common engineering language. They know that the list of variables and data structures is endless.

We Need to Stay Focused on Integrated Protection and Interoperability

I take issue with the need to do this for configuration parameters and operating parameters; those are not required for automatic operations. Those parameters that are set by an operator to configure a device and to establish the set points of a device should not be codified as enumerated data variables and structures. Rather, engineering tools provided by device vendors should be used to establish the settings of these parameters. It is true that using multiple vendor tools will increase training requirements, but this is not a communication protocol issue. Developing a standard browser and graphical user interface is a valid subject for another forum.

What is needed for interoperability and self-description is to store all configuration parameters and operating parameters, for devices commissioned for operation in a substation database. Self-description then becomes a simple matter of using the proper query tools to manage these parameters. Automatic operations that require access to this database should be designed using a standard interface definition language such as used for Microsoft’s Distributed Common Object Model (DCOM) or for Object Management Group’s specification of the Common Object Request Broker Architecture (CORBA).