Sioshansi F.P. Smart Grid: Integrating Renewable, Distributed & Efficient Energy
Подождите немного. Документ загружается.
value on July 1 is 11,000 kWh, a difference of 1,000 kWh. If
the sum of the 720 intervals differs from 1,000, one or more
of the individual hourly values must be incorrect (or the
register function has experienced an error, which is also a
possibility). Ensuring data accuracy requires an IT system
that can perform such a sum check and then provide
information that can determine the source of the problem. The
solution is not trivial, because the source could be one or
more inaccurate interval recordings, an inaccurate register
recording, or one or more missing intervals.
Mis-Programmed Devices
Another common source of accuracy errors is improper set-up
of meters or devices. Meters for large commercial customers
often have a “multiplier.” A multiplier is used when only a
portion of the current is passed through the meter. This is
needed for high-usage commercial accounts, because passing
the entire current through the meter would damage it. As an
example, if only one-tenth of the current is passed through the
meter—this is accomplished using a current transformer/
potential transformer combination (CT/PT)—then the
consumption recorded by the meter must be multiplied by 10
to deliver accurate total consumption values. If the system is
programmed with some other value—say 20—then the
reported value will be inaccurate.
The IT system can identify mis-programmed multipliers in
different ways. One method is to compare total consumption
for similar customer sites; a major discrepancy can indicate a
multiplier error. Another common method is looking at
consumption history and any major change occurring
coincident with the timing of the smart meter installation. A
third method is looking at aggregated loads. The usage sum of
551
all the meters on a feeder circuit for a given time period can
be compared to the usage recorded at the substation for the
feeder as a whole. One source of discrepancy between the two
values can be mis-programmed meter multipliers.
False Zero Values
Another potential source of inaccurate data is false zero
values. A zero consumption value for a given time interval,
for example an hour, may reflect zero consumption, a power
outage, missing data, or some combination of the three
elements. All three elements are commonly seen in smart
meter systems, even though the frequency is often small.
However, if 1 percent of the values are zero—a not
uncommon situation—this would create over 7 million
questionable values per month for a million-meter utility.
Improper Meter Resets
A fourth source of inaccurate data is meter resets. Electric
meters have a continuous recording of total consumption,
much like the odometer of an automobile that records total
mileage. The continuous recording value is called a meter
register. Interval data are recorded by taking a snapshot of the
register at pre-programmed intervals—every hour, say—and
storing the result. However, occasionally a power surge or
other disturbance will cause the meter's register to reset. Such
a reset will distort the data, because the snapshot taken after
the reset will be a lower value than the snapshot taken at the
end of the previous time interval. To ensure overall accuracy
of the reported data for use in billing and for other purposes,
any resets must be identified by the utility's IT system and
accounted for. The specific utility business processes will
determine how to account for such a situation, but the most
552
common method is to discard the suspect usage interval and
estimate the proper value using industry standards.
15
15
Edison Electric Institute, Uniform Business Practices for Unbundled
Electricity Metering, Volume Two, Appendix 5—Interval Data
Validating, Editing, and Estimating Rules, December 5, 2000.
Data Systems of Record
The smart grid is creating an IT revolution in utilities.
Historically, IT has been implemented in “silos,” with a
single business unit responsible for a function from field
device through data collection to data processing in the
software application. To achieve the benefits of the smart
grid, communication networks and data must be shared and
involve multiple software applications—from billing to
demand response to outage management. A key strategy to
maintaining data accuracy and reliability in this new
environment is identifying and utilizing a system of record for
each data element. By definition, the system of record is the
system that “owns” the data element and is looked to as the
final source of authority as to the accuracy of the record;
users and other software applications cannot change the data
without the permission of the system of record.
The sections below provide further detail on why utility IT
silos developed, why systems of record are needed when
multiple applications share the same data, and how to
implement a system of record strategy.
Utility IT Silos
Utilities did not have to focus on systems of record in the
past, because they generally implemented data applications in
553
IT silos. For instance, the Customer Service Department has
been responsible for meters, meter data collection, and
processing of meter data in the billing system. Other uses of
meter data have been on an exception basis, such as providing
periodic outputs of meter data for use in rate design or
distribution system analysis. Another example is management
of capacitor banks installed on distribution feeders. The
Distribution Operations department has been responsible for
the capacitor banks, the electronic sensing and switching
devices installed on them (“remote terminal units”), the
communications network, and the application software that
controls the capacitor banks remotely and records the data
from them. Figure 11.2 illustrates such systems.
Figure 11.2
Utilities historically have operated IT systems in business silos.
Source: Chris King, MDM Implementation Course, October 2010.
554
In contrast, the smart grid requires sharing of data,
communications networks, and devices by multiple
applications. For example, smart meters provide data for
monthly billing, consumer web presentment, and outage
management—all using the same smart meters and
communications network. Inconsistent data cause customer
confusion, user concerns, and operational issues. To avoid
these problems, multiple applications need to use the same
data. Failure to do so can result in costs exceeding tens of
millions of dollars when multiple market participants, such as
power generators and retailers, are involved.
16
16
Chris King, Competition at the Meter: Lessons from the UK, Public
Utilities Fortnightly, November 1, 1996.
The Need for a System of Record
Sharing of communications networks and data requires not
only new approaches to application integration—connecting
the applications to the communications networks and
data—but also systems of record. Application integration is
addressed below. As a general principle, IT architects prefer
to avoid duplicating data, but if every utility application used
the same database, all of the applications would be slowed to
an intolerable level. The slowing occurs because each time
data are processed in the database, it taxes the processing
power of the computer server on which the database is
loaded. Examples of such processes include sorting, indexing,
adding or deleting data records, aggregating data, and creating
reports.
The internet provides many examples of how companies use
multiple systems to ensure rapid response times and consumer
satisfaction. One such example is the Apache Software
555
Foundation distribution network for open source software.
When downloading a software package, users are given a
choice of multiple locations from which to download the
software in order to ensure rapid download.
17
The Apache
Software Foundation's strategy ensures that any copy
downloaded from any of the duplicate sites is the same as the
“master” copy. The system of record approach enables this
result.
17
http://www.apache.org/dyn/closer.cgi.
Both for utilities and in general, a system of record, simply
put, is the system that is assigned responsibility for a
particular data element and is master of that element. An
example would be that the utility customer information
system (CIS)/billing system is the master of the monthly
electricity bill amount. This amount is utilized in other
applications, such as consumer web presentment of the bill
and bill comparisons used to inform customers about rate
options. If there is ever a discrepancy between the amounts in
the databases used by these applications to present data to
customers or prepare mailings, the system of record approach
dictates that the amount in the CIS is the correct amount.
System of Record Implementation
The system of record concept is straightforward, if not
necessarily simple to implement. The first step is designating
which system is the system of record for each data element
used in various smart grid applications. The next step is
ensuring that changes to the data element can be made only in
the system of record. In our example, the monthly bill amount
can be changed only in the CIS, not in the web presentment
software by the customer or in an eBill application where
556
customers can pay their bills online. Third, the system of
record approach requires that any changes made to the data
element are distributed, or propagated, to the other systems
using the data element. In the same example, if the bill is
changed in CIS, the new amount needs to be sent out to the
customer presentment and eBill applications, so customers
using those applications will then see the updated, and
correct, amount. Finally, there must be an ongoing
synchronization process to check periodically that the
different applications are continuing to use the same data.
This means that each of the “slave,” or subservient, software
applications must check back with the system of record to
make sure it is continuing to use the proper master data.
Interestingly, with deregulation, defining the system of record
also requires specifying the entity in addition to specifying
the application. The regulators determine functional and
performance requirements at a high level. These requirements
then translate into the specific IT system requirements for
implementation.
In Texas, the distribution utilities are responsible for meters
and metering data, even though retail providers are
responsible for bill calculations. Accordingly, if there is a
discrepancy between the metered usage in the distribution
company's database and the retailer's billing file, the retailer
must defer to the distribution company's information.
18
18
Public Utilities Commission of Texas, Order Adopting New §25.130 and
Amendments to §§25.121, 25.123, 25.311, and 25.346 as Approved at
the May 10, 2007 Open Meeting, May 10, 2007.
In Ontario, policymakers felt strongly enough about this issue
to mandate, in regulation, the system of record. The
557
province's central MDM/R is the system of record for all
meter reading data. The distributors maintain the system of
record for all customer data, including any current energy
supply contracts with retailers, providing regular updates of
any customer changes to the MDM/R.
In the United Kingdom, the centralized Data Communications
Company (DCC) is to perform this role for all 54 million
electric and gas customers.
19
The government has concluded
that the scope of DCC should be developed in a phased
manner. When DCC starts providing its services, its scope
will cover secure communications, access control, translation,
scheduled data retrieval and central communications, and data
management of initial smart grid functions. The UK
government says that by limiting DCC's initial scope to these
essential functions, an earlier implementation date will be
achieved for DCC's services than if registration or other
services are included. The government's strategy is to support
the rollout plans of suppliers and the early delivery of UK
Smart Metering Implementation Program benefits.
19
UK Department of Energy and Climate Change, Smart Metering
Implementation Programme, Response to Prospectus Consultation,
Supporting Document 4 of 5, Central Communications and Data
Management, March 2011.
The UK government's strategy is a good example of how to
implement a complex IT system in the smart grid world. The
strategy includes two key elements: a long-term vision and
incremental implementation. The vision contemplates the
addition of new functionality over time, including support of
new technologies. This minimizes the risk of technology
obsolescence. The step-wise implementation maintains focus
558
and reliability. Each set of functions is implemented in a
phase. During the phase, the functionality is built, installed,
and thoroughly tested. Subsequent phases can then focus on
the additional functions that can be added later. Examples of
utility companies that have used this approach very
successfully are Toronto Hydro and CenterPoint Energy, as
well as the case studies described later in this chapter.
Communications Management
The challenges associated with communications management
for the smart grid are created by two basic aspects. The first is
the scope, which includes multiple device types and
potentially tens of millions of endpoints. The second is the
associated maintenance; communication links must be
maintained over wireless and other networks susceptible to
occasionally spotty performance. The challenge has some
parallels to maintaining large cellular phone networks, except
for the variance in devices and lack of current interoperability
standards for smart grid data—a key reason the industry is
putting so much effort into creating those standards.
Smart Grid Device Tracking
Smart grids include smart meters, in-home displays, smart
thermostats, smart appliances, and other equipment. Having
successful communications with those devices requires
knowing about them. The system needs to know everything
about them. This requires an IT system that can track many
details, and those details change periodically; for examples,
when installing new devices, changing the programming
(configuration) of devices so they operate or communicate
559
differently, and changing the software (firmware) installed in
the device electronics.
The following are several of the items that need to be tracked
to enable successful communications:
• Where devices are installed,
• What data they are generating or receiving,
• When such data are generated or received,
• What system, or systems, is ultimately exchanging what
data with the device (e.g., the outage management system
would receive outage alerts—“last gasp” messages—while
usage data would be provided to the billing system),
• What third parties, if any, are authorized to exchange data
with the device (e.g., in Texas both the contracted retailer
and the distributor), and
• What firmware version is installed in the device.
These data elements are tracked in a database with a data
model that can accommodate each element, such as that
shown in Figure 11.3.
560