Network Control: Intelligent technology

By Dr William T Shaw Hathaway Industrial Automation

The New England ISO manages the coordination and dispatching of electric power from over 150 generating units scattered around the Northeastern regions of the USA. These generating units range in size and complexity from nuclear plants to “hog fuel” fired cogeneration units at paper mills. The ISO runs a sophisticated energy demand and pricing model that updates unit commitment, dispatch point and pricing information for each unit.

Figure 1. Designated Entity interface alternatives supported for New England ISO
Click here to enlarge image

The ISO needed an automatic, reliable and auditable mechanism for delivering this data to unit owners and for receiving verification from these owners. The ISO elected to make use of Remote Intelligent Gateway (RIG) technology, combined with commercial frame-relay networking, to address this need.

The New England ISO, like other ISO entities formed in the US, has the responsibility for coordinating with the participating generator owners (called “Designated Entities” or DEs by the ISO) to purchase power and match generation supply against demand. In order to accomplish this task the ISO uses an EMS system to model the demand and produce five-minute “dispatch point” updates (including ramp rates, pricing data and operating mode data) for every unit.

The means of communicating this data automatically every five minutes, as well as notification of deviations from the schedule and adjustment to plan, had been under review due to the emerging technical, commercial and legal requirements.

Technical requirements

Within the ISO, the EMS system is interfaced with a “shadowed” Oracle data warehouse and all of the dispatch information is maintained within that data warehouse. The delivery of data requires a means for extracting data from the data warehouse, sorting it by DE and unit, and then delivering the relevant data to each DE.

The automatic delivery of data from the ISO to the various DEs is complicated by the numerous ways in which the DEs decided that they needed data delivered. DEs with plants run by DCS systems wanted a direct connection to and from the DCS system. DEs with multiple units scattered around New England wanted data delivered into a corporate server. DEs with units run by “analog” panels wanted physical I/O for selected signals and some sort of web page delivery of the remaining data.

All of these various mechanisms were required to be bidirectional so that receipt acknowledgement and data “reflection” messages can flow back to the ISO, to be stored into the data warehouse as an audit trail. The dispatch, ramping and pricing information being delivered to the various DEs is considered to be of a proprietary and potentially competitive nature.

Thus, communication security and privacy is an issue.

Figure 2. Function modules and HW/SW interfaces supported in the ISO-NE RIGs
Click here to enlarge image

In addition, the liability of mis-delivering data can be serious in a deregulated market, therefore the ability to audit and validate data receipt is very important. Of course, controlling the stability and sufficiency of supply requires that delivery mechanisms be reliable and robust. Thus some level of fault tolerance is necessary.

The RIG design

The solution that has been implemented by the ISO to address these needs and requirements is based upon RIG units, similar to those used by the California ISO, interconnected by redundant commercial frame relay networks. The individual RIGs are located at the DE’s specified “delivery location” (which may be a generating plant or just a corporate office) and connected to two separate frame relay service providers, via separate fractional T1 (56 Kbaud) circuits.

The RIGs provide several mechanisms for data delivery (as well as acknowledgement and receipt return) to the DE: serial interfacing via Modbus (or Modbus-plus) channels, ASCII file delivery via “ftp”, physical I/O signals and several others. The intent of the ISO was to offer a flexible number of interface options that would accommodate nearly every DE’s needs.

Data warehouse interface

At the primary ISO operating site RIG-compatible workstations use SQL queries to interrogate the Oracle data warehouse every five minutes and they extract the DE-specific unit information settings. The data is then sorted by DE and by unit and data update messages are constructed for transmission to the individual RIGs.

The communications between the workstations and the RIGs is done using a publish-and-subscribe application layer that “rides” on top of TCP/IP. This application layer requires end-to-end verification and acknowledgement of receipt from every RIG. If errors occur the workstation will make numerous attempts to make the delivery. Dual frame relay links are available to the workstations as well as to each RIG. If a RIG cannot be reached on one WAN, the workstation will attempt to communicate on the other. This is done on a per-RIG basis, and not as a total “fail over” to a backup network. Some RIGs will be “reachable” on one WAN and some on the other, although normally they are accessible on both. The workstation and RIGs continually “test” communication connectivity and alarms are generated if faults are detected.

Because the data being communicated is proprietary, the actual messages between the workstations and RIGs are encrypted. But the RIGs won’t communicate with any workstation until the workstation and RIG exchange digital certificates. The RIGs and workstations form a Virtual Private Network (VPN) which effectively protects the ISO from “hackers” and accidental delivery of data to parties who should not have access to that information.

DE interfacing

One of the most challenging aspects of the project is the need to provide a “generic” RIG with a flexible assortment of interface options that would accommodate the highly disparate requirements of the various DEs. The final design incorporated several mechanisms for both delivering dispatch data updates to each DE, as well as complementary mechanisms for returning responses and acknowledgements from each DE.

The RIGs are equipped with local video display and keyboard interfaces, as well as audio outputs for DEs that manually monitor the data updates. Each RIG also hosts a web server with dynamic web pages that provide data display and input mechanisms.

To get the attention of the operator/user, the RIG provides audible annunciation as well as contact outputs that can be hard-wired as required. Automated data exchange is provided using the RIG as an “ftp” file server via one or more serial communication ports that mimic a PLC using Modbus protocol. One final option is the ability to deliver a selected set of values and status flags, and return similar information in the form of analog and contact I/O signals.

Expanded role

At the end of the summer of 2000, over 60 DEs were interfaced to the ISO through the RIG network. At the start of the summer of 2000 the workstation equipment was installed in the two control centres and a couple of RIGs were installed in the field for preliminary testing.

After a reasonable field test period the RIG deployment began and between five and eight RIGs were installed and commissioned each week. Teams of installation technicians travelled around New England verifying site readiness, installing the RIGs and performing end-to-end “live” tests. Several additional DE’s are scheduled to be integrated into the system by the Autumn of 2001.

The ISO has plans to expand the role of the RIG network to provide real-time data acquisition, AGC control of the generating units and secure transport of meter data. When the ISO selected the RIG technology they assured the various DEs that the RIG would be the platform for implementing these other functions when the time came. The DE’s were very vocal about not wanting to have to invest in separate technologies and equipment as the ISO phased-in additional programmes.

Fortunately, based on the experience of the California ISO, the RIG technology has been field-proven to support all of the requisite functions outlined in phase two of this project.

No posts to display