WiseOwl™
The Secure Automation
Developer's Resource
|
|
Basic principles for object-oriented device networkingDennis Holstein, Publisher
|
 | Inexpensive user interfaces. A communication port can link an IED application to a browser-based interface. This interface is significantly cheaper than an LCD screen, with its many buttons and manuals. |
| Remote access for control and monitoring. With each new design that incorporates a microcontroller, there needs to be access to information stored in the IED. |
| Integration of web-based information sources with IED applications. In a deregulated energy market, there are many instances from having access to information from the outside world. |
| Distributed control systems. Many applications of IED communications involve making several computer systems act like one. This type of application is often motivated by the desire to reduce wiring cost to a central controller. Another example is when a single system is built from a set of unknown components. |
To address this need, EPRI tasked the RP3599 team to develop a test and evaluation laboratory. EPRI also sponsored demonstration projects to bring teams of vendors and utilities together to build prototype systems comprised of interoperable IEDs from different manufacturers. Although EPRI's test and evaluation laboratory no longer is active, several of the utilities have invested in their own labs to ensure that a prototype is well thought out before deploying the substation automation system.
In some advanced labs and demonstrations, there is an IED-resident server that makes a set of functions, variables, and events available for remote manipulation by web-based clients. In effect, each IED is encapsulated as a single device object in a web-based proxy server. The IED object can be manipulated from remote interfaces using C, Java, or ActiveX APIs (Application Program Interfaces). The IED object has a complete description of each function, variable or event.
However lack of typing and any sort of behavior contract can create serious problems, and will make it difficult to build larger systems. What is needed is an IED network infrastructure that is automated in terms of configuration, maintenance, and operation. The result should be that any information on an IED should be accessible by network resident applications through standard database APIs. The database APIs should also be used to affect the state of many IEDs, not just a single one or a single type. When one IED has information relevant to the operation of another, this information should be transferred according to predefined rules for interaction.
Manufacturers have developed thousands of IEDs with connectivity in mind, and devices with connectivity have incorporated RS232 ports with custom protocols. Although these proprietary protocols may implement commands for diagnostics, data logging, and device control intended for use by other IEDs, their level of interoperability with disparate networks is limited. Of course the benefit of this approach is that it is simple and relatively inexpensive. However the problem with IEDs that use this limited form of connectivity is that they are not scalable, and cannot integrate higher level systems. Someone has to look at each and every IED type and create a translation module. This is not a simple process because of the lack of protocol standardization and abstraction.
With this in mind, the RP3599 project team focused its attention on creating uniform interfaces to object representations of IEDs and use standard class definitions to describe similar IEDs. The Unified Modeling Language (UML) was selected to standardize the object representations. UML continues to be the choice for development of IEEE P1525, IEC 61968 and IEC 61970.
For some strange reason EPRI's development of GOMSFE (Generic Object Model for Substation and Feeder Equipment) and IEC 61850 decided not to use UML, but to use a non-standard modeling language. Even though they do not use UML, they reach the same objective. It is left to users to map GOMSFE and 61850 objects to objects defined using UML.
By creating uniform interfaces, using UML, and creating standard class definitions, the task of creating useful software applications that incorporate IED information can be decoupled from the task of getting that information from the IED. Additionally, the IED representations define a behavioral contract, which is a prerequisite to any real progress in the automation of IED network configuration and management.
We start by describing a substation automation system that lets you encapsulate an IED into one or more objects. Each of these objects is essentially an instantiation of a predefined IED-related class. Typical implementations include class implementations for management, the general IED application, and a class for proprietary extensions. The management class implements features used for version control (software and firmware upgrades), capability discovery, device identification, and performance related tuning. The class that represents the general IED application is essential the feature set of the virtual base class for the specific type of IED -- called a "Virtual Device." Examples, or specializations, of Virtual Device are Relays and Switches (Breakers, Reclosers).
At first glance, the encapsulation of an embedded device application into an object appears to be trivial. The need for an industry-wide IED specification is apparent when you want to ensure "plug-and-play" and interoperability capabilities. Given a way to let the device describe which classes and interfaces it has implemented, and a protocol to allow manipulation of the device objects, the desired automation should be within reach. But problems start creeping from several different factors:
| An IED manufacturer adds product features to differentiate its product from other manufacturers. If these features are available to other IEDs, then a combinatorial explosion occurs, which removes the usefulness of the objects for software that relies on uniformity. A class definition based on the feature set of the lowest common denominator allows the notion of polymorphism at a substation automation system level. An interface can be written to this object. The question remains whether treating all devices the same offers enough value from interoperability to prevent manufacturers from ignoring standardization efforts. |
| Different aspects of an IED's operation will be exposed as different objects or interfaces within an object. However, each of these is accessed through a communication link that is often bandwidth limited. This brings up a host of quality of service issues, include questions of timing: Do the class definitions need to specify required responsiveness of the objects being used? Will spurious delays break some applications, particularly protection applications? |
Inheritance in the IED-networking realm is an interesting feature. The implementation of inheritance needed for substation automation is a distributed inheritance. IEEE P1525 specifies substation IEDs that can implement distributed inheritance.
IEC 61850 does not use a true objecting oriented approach, it uses a modified version based on data objects -- sometimes called passive objects). Inheritance is implemented using a naming convention, which means that IED objects are implemented in software within the IED, thus providing local inheritance.
Distributed inheritance provides the capability to implement the base class of an IED object on a larger device gateway, such as the substation computer; the subclass is implemented on the power system device such as a relay, switch, or a measurement unit. The substation host then further subclasses the power system device or measurement unit. This lets one control the final presentation of an object from a substation host.
The distributed class hierarchy that implements this type of inheritance allows one to create a IED application that is based on services that are available through a supporting system such as a substation host.Given an IED network of objects, the next step is to create bindings between the objects. One approach is to create bindings between the properties, methods, and events of various objects. There are a number of ways one can approach this.
| Make a set of IED objects and interfaces available from each IED. Then make that set available to some configuration process. The configuration process then determines what the overall interaction should be and binds the methods and properties of the objects as appropriate. If the underlying communications stack does not allow peer-to-peer communications, then the binding is accomplished through an intermediary node that acts as the bus master and spends a lot of time copying data around. |
| Implement the interactions between IEDs adding remote object manipulation features to the IED, then program the IED application to use remote device objects. |
| Implement a notion of object input for the needed objects, but let some external module control the remote object interaction and binding. Using this system, the IED is not the only thing typed. The input to the IED is from the binding with a specific type of object. This is stronger than simply binding to a property of an IED because the type of the IED supplying this input is enforced. The idea here is to keep the application developer from having to deal with the complexity of network configuration and management. Instead, the IED firmware/software is created with a set of predefined interactions with other known IEDs. |
In all these scenarios, the binding phase presents a problem. The desire is to have a completely automatic plug-and-play type of system. The reality is that the binding of IEDs is often difficult or impossible to resolve automatically. The process of binding IEDs into control systems must be accomplished by:
| Discovery of available IEDs. |
| Designation of suitable bindings. |
| Binding the IEDs. |
| Confirmation of correct binding. |
One or more of the stages can be automated or skipped, but not all of these steps can always be skipped. With an object-oriented approach, IED networks can be built that are automatically configured and efficiently managed, but there is no magical property that can make what would be essentially a random guess into a wise choice.
Earlier I suggested that IEDs might be implemented using inputs that are of certain class objects instead of using inputs from properties that are manipulated. This is an important choice because, on one hand, you get IEDs that cannot possibly be connected to inappropriate input. On the other hand, you risk losing flexibility and the ability to bind inputs to reasonable but unanticipated sources.
Bidirectional contracts are good when the behaviors for given inputs are easy enough to design, but then the inputs should be more strongly typed. If one views the inputs as classes, then this is done for you already because the contract is extended to include the appropriateness of the inputs to the IED. GOMSFE and IEC 61850 are good examples of strongly typing the inputs to extend the contract.
IED networking and object-oriented design are a natural fit because object-oriented design is premised on modeling real world power systems and relationships. When embedded applications can be treated as instances of standard IED classes, the IEDs can be integrated into larger, more automatic systems. To accomplish this automation, the IED application developers must not only create an instance of the IED class, they must be able to structure the relationships of their applications and other IEDs. Having this type of object-oriented approach to IED networking lets one vastly simplify the end-user's environment by making IEDs work together without needing an end user to be tied to the system.
As IEDs find their way into more and more substation automation applications, the systems will implement behaviors appropriate for their limited inputs. Many of these substation automation systems will have valuable information available to them that is never made available to the control center or engineering. This is sometimes due to cost, location, or for the sake of simplicity for users. By adding networking between the substation, control center and engineering, one can tie these isolated systems into larger coordinated systems. The components of the larger systems may be created by different vendors, but should be easily, if not automatically, connect and work together.
This requirement is familiar to software developers who have dealt with software interoperability issues for many years. The tool developed for this problem of interoperability is object-oriented design. In IED networking, an object-oriented approach of encapsulating IED capability into classes facilitates network configuration and provides strong typing require for ensuring the appropriateness of the interaction. However, the relationship created by merely encapsulating capabilities, then using them elsewhere, does not sufficiently guarantee to the manufacturer of an IED that the IED will be used appropriately.
The developers of GOMSFE and IEC 61850 specify standard classes which is a prerequisite for automated IED network configuration control and management. They further suggest that only by tightly defining and describing all data objects, their semantics and their structure, can one be assured that automatic configuration will be achieved. Utility demonstrations will in time tell how well this works.
Send mail to postmaster@opusss.com with questions or comments about this web site.OPUS Publishing and OPUS Subscription Service are trademarks of OPUS Publishing.
All other products mentioned are registered trademarks or trademarks of their
respective companies.
|