Comment

01 June 2003

A sensor enabler

By Andrew C. Montz

After sensors get the numbers, XML collects, shares vital data.

Energy suppliers, distributors, and marketers have become major adopters of developing Internet technologies that collect data from heterogeneous devices and exchange information among otherwise incompatible systems.

Chief among these technologies is extensible markup language (XML) documents, which describe data and its structure and can be exchanged over Internet protocol (IP) networks using hypertext transfer protocol (HTTP). Ethernet and XML have a great future in factory floor and other environments as well.

Although XML is not for high-speed, critical control, it is a superb data transfer and configuration tool, enabling devices at all levels to identify one another and communicate data. XML offers an excellent bridge between enterprise resource applications and control programs. Furthermore, XML over wireless networks can link all sorts of devices to systems.

In the arena of electric and gas demand-side management, larger energy users are seeking fast, accurate methods to determine current and historical use. In California, the state's responsible agency has mandated the largest demand facilities to provide near-real-time electric energy use and generation data via IP networks.

Facilities such as municipal airports or large industrial plants had to upgrade to expensive new IP-enabled meters. Most meters in place at a city's facilities—even those at large energy users such as water treatment plants—can exchange information only via file transfer over a modem connection or not at all.

A smaller city cannot determine its total energy use except after the fact. The basis for a city's electrical rates comes from total consumption plus peak rate usage. To calculate total and peak rate usage charges, the electric provider typically downloads, once a month, files containing 15-minute electric use data.

In 2001, one small Midwestern U.S. city embarked on an effort to get 4-second updates and 15-minute usage values as soon as they were available at the meter. The city wanted to know its demand and do something about it in a timely manner.

Saw $24,000 a month savings

The city's effort was undertaken principally because its electric bill is based on nontime coincident separate demand peaks from about 50 meters. When compared with billing based on the single peak of the aggregate demand, city energy managers calculated they could save about $24,000 per month using an aggregated use rate structure. In addition, the city expected to realize immediate significant savings, even with the existing rate structure, by identifying individual meter peaks that could be reduced by better activity scheduling.

The city believes its ability to publish accurate 4-second and 15-minute aggregate load and generation data to energy suppliers will allow suppliers to better manage reserves and distribution resources. A portion of the resulting cost savings theoretically could be passed on to the city through renegotiated rates that take into account the improved information availability.

In the project's planning phase, some vendors suggested the first requirement should be to replace all existing meters with vendors' IP-enabled units. That alone would have exhausted the city's project budget and yielded not one piece of data. Vendors also suggested a new dedicated IP network would be required to support their bandwidth-intensive data collection schema, which involved polling every meter every 4 seconds with vendor-supplied software.

The city, however, sought innovative solutions to obtain needed data from its existing older meters and use its existing information technology (IT) network capability. It opted to try an alternate approach in which existing meters were IP enabled by adding gateway devices that interfaced to the meters via digital contacts or serial ports.

The gateways pushed XML data documents over any existing IP-enabled media to a central Microsoft SQL Server 2000 server. This approach used the existing infrastructure and therefore had an inherently lower cost. By transmitting only when changes occurred and always on 15-minute time boundaries, network traffic was kept to a minimum. (Details of XML document processing, illustrated with example documents and SQL processing steps are available from amontz@dr-das.com.)

XML technology 'open'

XML documents can support universal/ open data acquisition and exchange protocols. An XML document is a text file that uses the concept of tags in familiar HTTP Web page documents. However, in XML, tags and attributes describe the data instead of telling how to present text and pictures. An XML document by itself contains only the tags and values. XML documents can deliver structured data from a wide array of incompatible devices. They can also facilitate server-to-server data transfer among machines with different database schema.

Major IT organizations adopted XML in part because its simplicity allows them to use existing program components, called parsers, that automatically dissect an XML document and make the data available to programs. The tags become field names in tables and record sets, and the tag values are data field values assigned to program variables.

XML, as defined by the World Wide Web Consortium, is a vendor-neutral industry standard. It enables devices such as programmable logic controllers (PLCs), meters, or pieces of analytical instrumentation to "talk" the same language. Data can be obtained in a generic format that programs and databases understand without having to deal with the native protocols of the devices. Of course, if a gateway is needed, it must interface to the device via one of the device's protocols.

While the XML document itself is just a text file with tags and values, various ways have been developed to automatically manipulate, transform, and format XML documents. Data presentation and processing instructions can be provided as separate documents referenced within the XML document. These documents are schemas and style sheets—key elements of XML's capability.

In addition, tightly integrating XML documents with databases such as Microsoft's SQL Server 2000 allow XML documents sent to a Web site to be parsed and used as the data sets for Insert, Update, or Delete statements in SQL.

This technology allows data from thousands of dissimilar devices anywhere in the world to push information "simultaneously" to a Web site and update a database. "Under the covers" database functions can then effortlessly process new information to present information such as current new electric use aggregated over all, or various subsets of, meters. Usage by department, building, region, and time of day are easily determined. The Web site and database processes can handle it all.

Gateways needed

New devices and instruments may publish their information via XML. For most existing equipment, however, a gateway device is used.

A gateway is a specialized Internet appliance server that acts as a bridge between multiple networks or between a network and a measurement device. A gateway may provide Web services and data management. An Internet appliance server is a specialized, limited-function device that runs Web services such as Web sites, ftp sites, and e-mail servers.

Appliance servers host information on the network and are often headless, having no direct user interface such as a keyboard or screen. They are application specific and optimized to manage data transactions as inexpensively and simply as possible using Internet protocols.

A gateway is typically an embedded device that obtains data from the PLC, meter, etc., caches the information, and makes it available as an XML document either on demand or by transmitting the document on a schedule or when changes occur.

A gateway serves as an interface to existing devices and obtains measurements from the device, processes samples, and stores data for subsequent transmission to multiple servers that then store it in unique table structures of the receiving database.

Specifically a gateway must:

• Obtain stored measurements
• Establish a network connection with the location(s) to which data is to be sent
• Submit the data in a generic XML format the receiving location can process
• Determine if the information was re-ceived and if not, schedule transmission

In a gateway process scheme, all remotes can be different, and all centrals can be different. It is the XML documents that contain sufficient information to allow receiving systems to determine how to process the data. Each receiver can process the data differently according to its own unique needs, but it need not receive the data in its own unique format to accomplish this task.

Gateways will typically support a variety of network connectivity options. These include Ethernet (direct), modem (V.32, V.34, V.90), cellular digital packet data (wireless wide-area network), and 802.11 (wireless LAN).

While most of the city meters already existed, several new installations were done. IP-enabled meters were not installed. Instead, the city opted to combine a meter with a Protocol Specification for Electric Metering (PSEM)-compliant serial interface (ANSI C.12.18, ANSI C.12.19 for communications and data tables) and a meter gateway. The rationale for this decision included the following:

Unlike meters, gateway costs are projected to decrease rapidly. The network access, data caching, Web access, and computational ability features are expensive options in meters. By using a gateway for these features, overall cost is reduced.

Network connectivity options built in to the available meter options are limited. Other than direct network connections, external gateway devices supporting other IP-enabled communications will be required.

The lifetime of meter technology is upward of thirty years, while IP network technology is obsolete in five years. If the IP technology is embedded in the meter, you will likely replace the meter many times at greater expense rather than just upgrading an inexpensive gateway.

Many existing meters can be included in a system using gateways. New meters do not have to be bought, and expensive installations involving high voltage do not have to happen.

Example application

A system built on existing and proven component off-the-shelf hardware and software technology was built to meet project needs. Extensive use was made of Microsoft's .NET Server technology. Push, rather than pull, technology was used to efficiently and rapidly transmit meter data to a central cluster server array, where data was automatically aggregated and analyzed. The system, as designed, will scale easily and support thousands of meters physically distributed anywhere in the reach of the Web.

In the project, multiple meters were already connected to PLC or building management networks. This situation was used to advantage by adding an OLE for process control (OPC) or XML server to each such network. A Visual Basic 6.0 program was used to communicate with PLCs in two control systems and with a Modbus port in an existing building control system. After polling the data, the values were published via OPC and XML. This allowed OPC client applications to obtain the data. The XML documents went to the central server.

For meters not connected to an existing system, an Internet appliance server acted as a remote communications gateway. For most meters, only KYZ contacts were available to obtain electric use. The KYZ interface to these digital pulse–initiated electrical and gas meters adhered to requirements for pulse counters found in ANSI standard C12.1-1995, Code for Electricity Meters. The gateway's serial port was used to communicate with electrical meters supporting the PSEM protocol.

Data collected or calculated by the system included power kilowatts, energy kilowatt hours, electrical volts, electrical amperes, power kiloVARs, energy kiloVAR hours, and power factor.

The majority of the installed base of electric meters supported only a KYZ pulse interface. With that interface, each closure of a contact indicates that some fixed number of kilowatt hours (kWh) have been used. To determine the power (kW), the time between one pulse contact and the next is measured. Only kWh and kW can be reported for pulse type meters. New meter installations afford a serial interface option and additional data collection capability.

Meter data was sent to the central energy aggregation and information server as frequently as every 4 seconds, if the kW values had changed, and at least once every 15 minutes. At the server, the data was used to form hourly and daily values.

XML simplifies task

Use of XML documents for transmission of data to server databases is a simple task using tools such as those provided by Microsoft. These servers can also easily supply data sets as XML documents to allow data to be openly shared with any application.

The installed base of meters and other similar measurement devices does not overwhelmingly support IP interfaces and XML. It relies on a host of different protocols.

Using gateways to interact with other devices and push the acquired data to server databases provides a common language protocol and Fast Ethernet communications without replacing the measurement device itself. This option should be considered in system designs as an alternative to new and possibly more expensive meters with IP options. ST

Behind the byline

Andrew C. Montz owns DR DAS in Austin, Texas (www.dr-das.com). DR DAS specializes in data acquisition for energy and environmental monitoring systems. Typical applications involve IP enabling an existing instrument infrastructure, warehousing data in a SQL database, and providing Web distribution of data-centric information products. His e-mail is amontz@dr-das.com.