The Semantics of Not Puttingthe Ferrari in the Back of the Truck

The Semantics of Not Puttingthe Ferrari in the Back of the Truck

By Lee Margaret Ayers, Oil Systems Inc.

As of late, there has been much talk about moving supervisory control and data acquisition (SCADA) and automatic meter reading (AMR) data out into the corporation. Utilities are experimenting with many different options to do this. Some options include writing a subset of the data to a relational database, or routing SCADA data directly through the WAN, or creating an application/database to temporarily store and utilize the data for a specific application. These solutions are often limited in functionality and are cumbersome to use. In the long haul, home-grown systems tend to perpetuate the nightmare of island-automation within the corporation. What utilities and their research organizations do not realize is that there is already a robust technology that complies to standards. This technology will also exceed any of the results they wish to achieve a hundred times fold for less cost and in less time. This technology is known as a “Process Monitor,” or what I have come to call a “Real-Time Data Historian (RTDH).”

So what is a RTDH? The historian is basically a flight recorder for real-time or temporal data. It archives data, as well as serves out real-time data to the corporation. Data can be accessed from some of these systems in a variety of ways. An Applications Programmer`s Interface (API) allows mission critical applications to be developed using real-time data; a compliance to ODBC will allow the archive to respond to structured query language queries; client applications that are OLE compliant can be very powerful tools for the corporation. Ad hoc trending and calculations within desktop applications, such as Excel, represent complete applications for engineers designing new applications.

There are many business reasons why utilities invest resources to integrate their SCADA/AMR data into the corporation; the primary reason is the market. As corporations become more conscious of costs and competition, they will begin to use the data related to their history of operation more strategically–to monitor performance and minimize maintenance; to monitor usage and develop time-of-use pricing; to simultaneously monitor the usage and evaluate the market, and then decide whether or not to shed load for resale. Other industries have been optimizing the business-engineering process for years. Millions of dollars have been saved in the pulp and paper, oil and gas, refining and petrochemical industries because the history of operation could be analyzed, the margins of operations understood and the processes optimized.

SCADA and AMR systems are not alone in the menagerie of time-based databases that exist or are being created daily. Other types of systems on-line may include, and not be limited to: smart relays, remote terminal units, programmable logic controllers, substation equipment, distribution automation, large industrial meters, etc. I have coined these as “temporal” databases. Unlike corporate asset and business data that are generally transaction-based, temporal data is a continuous stream of information related to the plant or asset; it is simply a measurement and time-stamp. Information at the asset and business levels changes on a daily to yearly basis. Information at the temporal level changes on a sub-second to sub-minute basis. While there is a convenience in having all data in a single vessel, and thereby reducing redundancy and management to another database, what has been overlooked is the nature of temporal data and how it fits into systems designed for transactions. I liken it to the difference between a Ferrari and a 16-wheeler.

If you were in a race from New York to San Francisco and were given a choice of a fire-red Ferrari or a smoke-black, fully stocked 18-wheel trick tractor trailer, which would you choose? The Ferrari goes to speeds in excess of 170 mph. The 18-wheeler will certainly go 100 mph on the “straights.” If you pick the 18-wheeler, you must also deliver and pick up many postal packages along the way. The Ferrari seems like the obvious choice in a race. Would it make sense to pick both vehicles and put the Ferrari in the back of the 18-wheeler? It would if we were not planning to drive the Ferrari, and we were in a postal race–that way the Ferrari would be there if we ever wanted to drive it. Loading and unloading it would be a bit cumbersome, but we could do it.

In the example above, the Ferrari represents a temporal database (SCADA possibly) and the 18-wheeler represents a relational database (RDB). The decisions between which vehicle to choose seems so apparent, yet in the utility world, systems are being designed with a Ferrari in the back of the 18-wheeler. This is because those fine moving vans are a corporate standard. For transaction-based management of the asset, RDBs work perfectly well. But for time-based analysis of operational information, such as producing a trend for a piece of equipment for a two-year period, access and retrieval of data is much slower in a RDB. In addition to speed and performance issues, there are storage issues related to the RDB. Because the quantity of information from temporal systems is so great, some of the information must be dropped in order to store it in the RDB. This would be like arbitrarily throwing away some of the packages that need to be delivered–not knowing which packages contained a check and which simply contained a greeting. If we were monitoring a piece of equipment at a two-second scan rate and storing one piece of information into the RDB every 15 minutes, this would be equivalent to throwing out 450 pieces of mail for every one piece that was delivered. The post office would not do that. Why do we do that as utilities? Because we have yet to understand the value of the data we spend so much time and money to collect.

An RTDH is a cross-breed of the Ferrari and the 18-wheeler. A Ferrari engine is in the front and a minivan is on the back. This high-powered vehicle has special equipment to shrink the packages to one-ninth of their original size–so more packages can be stored. There is also another special device that allows the packages to be scanned for importance, leaving all the possible checks and expensive packages to be delivered. Out of 450 pieces of mail, it is likely that there will be anywhere from five to 15 valuable pieces of mail, for an average of 10 pieces. A machine scans each package for value. The resulting 10 pieces of valuable mail will take roughly the same space in the Ferrari/Mini Van as one piece of mail in the Ferrari/18-wheeler scenario–only that one piece of mail in the Ferrari/ 18-wheeler is not likely to contain a check. In RTDH terms, data are reduced and compressed for efficient storage, access and retrieval. The difference in access speeds between a RDB and a RTDH is several orders of magnitude. The data are stored in a way that the value of the data are maintained. This will be important for the cost conscious, competitive utility.

If 20 engineers were asked to compute the load for 24 hours, or the peak demand for a day in the future, there would likely be 20 different answers. Imagine all the current projects within a single corporation that have some aspect of temporal data associated with them. What data will be used as a common input to a myriad of models? If different data sets are used, what is the value of the result of one model compared to another?

To be a competitive entity, the corporation will have to find cost-effective business models and applications where the margins of operation are consistent and well understood. As utilities move more toward a competitive arena, knowing the exact margins of operation will be critical for many business applications, including the buying and selling of power. The RTDH will be a key component of most models.

So what is meant by understanding the “margins of operations?” Much like the earlier process control systems, current methods of load management resemble a crude management of setpoint values. Setpoint is a desired value that has been determined to produce an optimal outcome–usually cost savings or revenue producing. Advanced control in the process industry represents many optimization loops where the setpoint values for each process are determined through trial and analysis. While generation is easily considered a process, transmission and especially distribution have been overlooked in this regard.

Let`s look at an example. Load management and control have largely occurred with historical loading information from the substations. However, the load distribution is generally unknown. In some locations, previously negotiated contracts allow the utility to interrupt the service to customer locations when a peak load is anticipated. When the need arises, a customer`s power is cycled off. The load information used to forecast the usage is typically crude, and the customers that are cycled off are cycled off whether their portion of the network is overloaded or not. As crude as it may seem, this represents the first step in optimizing the process of load reduction. The desired load represents the initial setpoint value in load control systems–maintaining the load to that setpoint value has financial benefits. After that, there are many more levels of optimization which can occur through advanced control–again like process-oriented systems.

To move to a more competitive stance of operation, or active load control, would require managing loads beyond emergencies. Response to emergencies such as shaving the peak load to prevent it from exceeding capacity produces a cost savings, but additional savings and opportunities are available. What if the algorithm for shaving the load could be improved by one-half percent or more? A half a percent over time would be beneficial if more power were available to be sold. What other algorithms could be added to this model to reach one-percent or more improvement? The following components of load management have their own setpoint values associated with a rate of return:

Equipment optimization for a reduction in equipment failure;

Equipment optimization for load losses;

More efficient peak shaping practices;

More accurate forecasting models for existing and future construction;

More accurate forecasting models for power purchasing;

Real-time, time series forecasting models for load reduction;

Minimize revenues lost by cycling off customers in areas of the network that need load reduction;

Load shedding for sale on the secondary market; and

Guarantee a fixed level of service for a specified rate.

Most people who are making decisions about the design and usage of temporal data will often consider their application alone. An upgrade to the system may be to have three months of data on-line instead of one. A company I know originally had six months of data on line instead of one. Through trial and error it realized that seven years of data on-line better met its needs. The tendency in the industry is to design “better than what we already are”–a “click” to replace function key, vector graphics instead of character graphics, three months of data on-line rather than one. It is not that these kind of upgrades are not valuable, because they are. It is that it is much different designing for the organization you want to become rather than designing for the organization you already are. Most systems implemented today are outdated shortly after implementation.

Current technological advancements in data collection and dispersal to the desktop will allow engineers to completely reshape the way current analysis is performed. Managing load (and other applications) will no longer be an engineering function, but a rigorous business decision. Maintaining the network will evolve into the management of the network. RTDH will play a key role in getting data to the desktop and as input for business-engineering applications. With all this said, remember what is most important–“the check`s in the mail.”

Author Bio

Lee Margaret Ayers is a T&D systems architect for Oil Systems Inc., acting as a consultant and educator to the utility industry on real-time historian technology.

Previous articlePOWERGRID_INTERNATIONAL Volume 1 Issue 2
Next articlePOWERGRID_INTERNATIONAL Volume 1 Issue 3

No posts to display