DC Power plants can be controlled and alarmed via the intertent

Monitoring and controlling DC power plants has evolved over the years, but the original problem still exists: What is the best way for the DC power plant to connect into the site-monitoring system?

Typically, users will connect individual Form C relays (indicating various alarms such as rectifier failure or low DC voltage) from the DC power plant into the overall site-monitoring system. Some pieces of network equipment have built-in site monitors, while others require the user to purchase a separate monitoring system. The monitoring system is then connected to the customer's network operations center (NOC). DC power plants are only a small portion of the overall network controlled by the NOC.

DC power companies have developed several remote monitoring and control systems. A typical system might use a modem or RS-232/485 connection between the headend station and the power plant devices. Custom application software or a "plug-in" implementing a graphical user interface (GUI) is supplied to the user. Once the software has been installed on the headend computer and the connection is established, the systems are able to provide a graphical interface to the DC plant for monitoring and control.

But does this solution consolidate all the site's alarming and controlling? In this case it does not.

Other solutions involve ASCII protocols to communicate control and monitoring of the DC power plant to a general purpose site monitor. This solves the problem of consolidating alarms but puts the burden on the installer to program the site monitor to accept and recognize certain ASCII characters and message strings from the DC power system. The lack of a graphical interface also limits the user's ability to adequately monitor large, complex systems. Upgrades or changes are almost impossible to implement because of the site monitor's limitations.

However, technology is quickly becoming sophisticated to provide an answer to these limitations. That answer can be found in the Internet.

The rapid decentralization of telecommunications infrastructure and the popularity of Internet applications such as Web browsing and e-mail have led telcos to invest heavily in the deployment and expansion of their enterprise-level networks based on the Internet (TCP/IP) protocols. These networks typically connect to both remote sites and NOCs.

A logical progression is to use these same enterprise networks and Web browsers for a new class of applications: configuring, controlling and managing DC power system control devices and functions.

A telco might react to this suggestion with concern about the overall expense of changing management methods. However, the company would have already borne the cost of installing its internal TCP/IP network, and most network stations are equipped with either low-cost or free Web browsers. It may be easier and cheaper than one may think to use the same network and browser software to monitor and control the DC power plant and the whole network site. Already, different approaches are allowing users to monitor and control their power plants via a network based on TCP/IP.

IMPLEMENTATION How can one configure a DC power system to be controlled and monitored via TCP/IP? One brute-force solution would be to embed the TCP/IP hardware and software into each DC power system component to be monitored, then simply connect these components to the network as one might connect a workstation or laptop. However, this simplistic approach has several problems.

First, the amount of hardware and software necessary to interface a control device to a TCP/IP network is fairly substantial. There needs to be a physical interface, such as Ethernet, and the device must implement the TCP/IP protocol stack. The cost associated with supporting these functions may be too prohibitive to include on each DC power system component.

Second, many modern DC power systems implement their functions in a distributed manner, using the network connection between devices to coordinate the actions between components of the system. Such communication is performed on a "peer-to-peer" basis. For example, a device measuring battery temperature might use a network connection to communicate real-time battery temperature information to an intelligent rectifier implementing temperature compensation control of the output voltage. This may necessitate a fair amount of network traffic between devices, which may not be desirable on a general purpose TCP/IP network.

A better approach is to implement the system using two network tiers. At the DC power system device level, a local area control network (LACN) connects the individual components together. Next, a TCP/IP gateway provides an interface between the LACN and the TCP/IP network, using the Ethernet twisted pair physical connection. The gateway is assigned a unique IP address and provides a window to allow all devices connected on the LACN to be monitored, controlled and managed via the TCP/IP network. A software architecture to support this two-tier approach is also necessary.

The first step in reaching this goal is to adapt a DC power plant with its battery chargers and ancillary panels to communicate alarms and control functions via the LACN. An important distinction between the LACN and a typical data network is that the LACN is optimized for control applications rather than data applications. Typical data networking technologies such as Ethernet are optimized for communicating large blocks of information.

LACNs, on the other hand, are optimized for short message blocks with timing that is much more critical. Because they are used for real-time control, LACNs must perform reliably under conditions ranging from light network traffic to very high traffic that may occur under certain alarm conditions such as AC failure. Also, the LACN must operate across a wide range and variety of parameters such as temperature and electromagnetic interference.

The LACN must be cost-effective, both from a device hardware standpoint and from an installation wiring standpoint. Some of the devices connected to and communicating via the LACN may be quite inexpensive.

Ideally, the LACN should be based on widely available, open technology. A solution built on open standards permits inclusion of third-party devices into the DC power plant monitoring system. For example, if an air conditioner or engine generator uses the same LACN standards, it can be connected and installed into the DC power system network.

This helps solve a huge challenge for telcos: How do you monitor and control a maddeningly complex arrangement of different devices from different manufacturers using a common network from a central NOC? The more devices that communicate via an open standard LACN, the easier the user's job is to provide connections to the site monitor.

With an open LACN, anyone can design a device that can connect and communicate to the PCP network. Support for DC power system nodes-such as battery monitor nodes, monitor nodes and rectifiers-is also important. Compatibility with third-party nodes supporting ancillary DC system functions such as HVAC control, engine generator control, security and access control, lighting control and other functions is a plus.

In addition, having a low-cost LACN is significant, as is traffic management efficiency that favorably compares to Ethernet management. A good analogy is to imagine that the LACN is a highway and that each device is connected to the highway with a gated on-ramp. In an Ethernet configuration, the on-ramp gate is always open. When a device wants to communicate something, it sends a car full speed ahead onto the highway. If the highway is full, the car crashes or backs up (collision detection) and tries again. If there are too many devices trying to send messages on this LACN, gridlock can occur. However, in some LACN configurations, the on-ramp gate to each device is always closed (Figure 1). When a device wants to communicate a message, it must wait until the highway has an opening in the traffic jam, and then the gate is opened (collision avoidance). Only then can a device send a message onto the network. It could be some time before the message gets onto the network, but eventually the message makes it to its destination.

Systems using LACNs have a great advantage over systems with Ethernet connections to each black box. When multiple events occur at the same time, large numbers of alarms can be generated by these black boxes. The LACN can act as a gating mechanism to control the traffic placed on the Ethernet network and prevent the network from becoming jammed. A jammed network means critical information may not get through. Another advantage is that devices can communicate with each other while being isolated from the Ethernet network.

The DC power system and other devices can now communicate via an LACN. But how does the customer communicate with the DC power system, and how can this be accomplished with readily available tools and interfaces? One way is to bridge the LACN to a TCP/IP network, thereby taking advantage of the power and flexibility of Internet technologies. Simply assign an IP address to the site or DC power system, bring a TCP/IP connection to the system, and point any standard browser to the IP address. You are now connected.

INTERNET GATEWAY The bridge required to connect to the DC power system is a computer with connections to both LACN and Ethernet networks. The Ethernet connection allows the user to connect the system to the Internet or intranet. The most important characteristic of the gateway should be reliability.

The operating system must be robust. It should consume little flash memory. This means no hard disk drives with moving parts and no battery backup while being field-upgradable (Figure 2).

The software required can be more difficult to define. The use of the Internet implies the use of Web browsers, which are good graphical interfaces. A good software goal is to design a "virtual instrument" for each black box or device, complete with interactive controls that can be manipulated by the user via the Web browser interface. Each device can be a software-configurable black box with external buttons, LED indicators and switches.

There are two approaches to this problem. One solution is to design GUIs as plug-ins that reside on the user's/customer's/network operator's machine. The user would connect to this system by launching this plug-in from their host computer and then connecting to the DC power system. Only data would be communicated over the TCP/IP network, and the plug-in would generate the virtual instruments.

Another solution: Have the GUI reside at the site in the Internet gateway-a resident virtual instrument. This can be done by using Java applets to generate the virtual instrument. No special programs need to be run before connecting to the site. The user would simply point the browser to that IP address and connect to the site. Both the virtual instrument and the data would be sent to the user via the Internet.

Which is the best solution? Compare four attributes: platform support, installation, maintenance and performance.

In terms of platform, the virtual instrument should appear the same on any computer or browser. If the virtual instrument is written in Java, any Java-enabled Web browser could be used and it would be platform-independent. For either a plug-in or a resident virtual instrument, Java would produce the desired operation.

For the plug-in solution, installation is required on each computer accessing the site. For the resident Java applet solution, no installation is required. The virtual instrument and the data are stored at the site and downloaded each time the system is accessed. The advantage goes to the resident Java applet.

Maintenance for the plug-in solution is very complex. New features would require not only updates to thesite's gateway but also to all plug-ins. Potential problems with version synchronization could occur for both the site and the user. Maintenance is simple with the resident Java applet approach. New features are added to the Internet gateway only. The user needs no updates, and different versions of the virtual instruments can be accessed using the same Web browser. The resident Java applet has a huge advantage in maintenance.

The performance of a plug-in is usually very good. Network speed is not an issue because only data is transported on the TCP/IP network. The performance of the resident Java applets is good and getting better as browser technology progresses. The only drawback is that the applet code must be downloaded each time the site is initially accessed.

In a trial administered by the authors, a 1 Mbyte file is transported over the TCP/IP connection when pointed to an Internet gateway. This file includes overhead and all the virtual instruments for the black boxes connected to the gateway. Once this file is downloaded, only a small amount of data is transported via the TCP/IP network for the remainder of the session. It is very similar to connecting to a Web site for the first time and waiting for the file to be downloaded. There is a small initialization speed advantage to the plug-in solution.

WHAT THE FUTURE HOLDS In the trial, third-party devices complying with the Lonmark interoperability framework can now be connected to the LACN. A virtual instrument can be constructed in Java loaded into the Internet gateway to monitor and control third-party devices. It can also automatically alert specific individuals when alarm events occur.

A Java based plug-in can be developed that, when launched, can successfully receive alarms pushed to that computer's IP address. Simply run the plug-in and add the remote computer's IP address to the designated "alarm push" addresses in the gateway. When a selected alarm occurs at the site, a snap shot of the virtual instrument is sent to that IP address. As the "Web push" technology advances, this feature may be available without a plug-in.

What advances will the Internet bring next year or even next week? Nearly all companies have an e-mail or intranet system. With built-in firewalls and outside protection, the infrastructure for a new telco is already in place. The established telcos have dedicated NOCs monitoring all of their sites or at least certain regions. They have their own intranet with Web browsers at each NOC (Figure 3).

If the infrastructure is here, there is no reason not to get connected.

Anthony Cosentino and Michael Sullivan are with Power Conversion Products, LLC, in Crystal Lake, Ill. Richard Baxter and Jon Loeck are with Pensar Corp. in Appleton, Wis. The information in this story was originally presented as a technical white paper at the Intelec '98 conference.