Authors: S. Neumann of UISOL, F. Wilhoit of need company name , M. Goodrich of Project Consultants, B. Murthy of need company name
TBD by B. Murthy i.
increased frequency ii.
decreased latency
TBD by M. Goodrich iii.
Power quality (outage and dynamic) iv.
Meter operating parameters/asset health
1.
Environmental
2.
Communication
TBD by M. Goodrich v.
Inside the utility but outside the meter vi.
Outside the utility
1.
Consumer-owned sources
2.
Partners, e .
g ., RTO, market, weather
Numerous information exchanges are associated with the deployment, configuration, maintenance, and control of meters. Many operations that previously required the dispatch of field service technicians can now be done remotely, at least in certain situations. Handheld in-field programming/troubleshooting devices that communicate with a meter’s onboard communication ports ( e .
g ., infrared) must typically be programmed from back-office systems; those information exchanges also benefit from standardization.
Meter deployment involves the initial configuration of the meter itself, as well as the establishment of linkages between the meter, the usage point where it is installed, the utility customer, and their service agreement. Tracking the linkage between the meter and its configuration load is an asset-management responsibility. The usage-point linkage conveys the meter’s physical location and therefore involves geospatial information and distribution grid management. The customer and customer-agreement linkages may be directly to the customer-information system, or indirect through the systems mentioned above.

Meter installation necessarily involves a visit to the premise, but utilities can realize very significant savings by performing post-installation operations remotely. Business and technical considerations that factor into the decision whether a particular intervention can be done remotely include security and the bandwidth and reliability of the communications network. Meter reconfiguration may be triggered by a customer changing to a different tariff, or by changes to the communications network or the reprioritization of classes of meter events (see Section 1.2., above).
Partial or full meter firmware updates fall into a similar category. Meter manufacturers often supply proprietary tools to perform these operations, such that the content of the data objects is opaque; but even where this is the case, it may be useful to standardize the data objects by purpose, e .
g . tariff descriptors, network routing tables, licensing/security parameters, etc.
The use of meter events, sensor readings, and error records to enable remote troubleshooting has been discussed above in Section 1.2. Findings derived from these sources of data may indicate that remote corrective actions are feasible, e .
g . corrections to routing tables.
The ability to perform meter control operations remotely is a core promise of AMI technology. This includes remote connect/disconnect operations and direct load control, as well as commands to configure and control PAN devices for which the meter acts as a communications gateway. These commands may reflect the fine-grained runtime implementation of decisions made by energy-market or distribution grid management systems, based upon
Locational Marginal Pricing, distribution system congestion, planned or detected outages, etc. It may be necessary to share such decisions in near-real time with utility partners such as RTOs, consumer-program facilitators, etc.
TBD by B. Murthy
There are a wide variety of systems that are deployed to meet the needs of electric utilities, with many of those systems having direct involvement with smart meters and the information the produce. The following diagram provides a perspective of the integration problem.
Meter
Customer
Electric Utility
Enterprise
Applications
(e.g. CIS, WMS,
GIS, MDMS)
Enterprise Integration
Infrastructure
(e.g. ESB, SOA, …)
Inter-Application
Information Exchanges
Operations
Applications
(e.g. OMS, DMS)
Head End
Systems
(Metering,
DRMS, DERMS)
Data Warehouses
Field
Device
Field
Device
Field communications using proprietary or standards-based communication infrastructures Inter-Enterprise
Information Exchanges
Partners
Partner
Applications
(e.g. weather, market)
Meter or
Gateway
Customer
PAN
Device
HAN/PAN
PAN
Device
Customer
PAN
Device
Gateway or
Controller
HAN/PAN/LAN
DER
DER

Where there are a wide variety of protocols and communication infrastructures used for field communications, a significant challenge has been to address information exchanges within and between enterprises and their related applications. This is especially true as new opportunities to leverage smart meter data are identified.
Note: we can add more text here to properly transition from sections 1a-e to sections 2 and 3.
The CIM has a package named ‘Metering’ that was defined for IEC 61968 to provide the extensions needed for the integration of metering systems. This has been standardized by IEC 61968-9 and IEC 61968-11. While there were over three dozen classes introduced into the CIM for metering, the key concepts include:

EndDevice and Meter, where end devices are a type of asset and a meter is a type of end device.

Reading, which is used to convey the data collected by a meter, where there is a wide spectrum of information that can be conveyed depending upon the capabilities of the meter

EndDeviceEvent, which allows a meter or any other type of end device to report a wide variety of event types

EndDeviceControl, where an end device can be instructed to perform a wide variety of actions (obviously depending upon the capabilities of the device)

UsagePoint, where usage points are reflective of a physical or virtual location for one or more end devices
The key to meter readings, end device events and end device controls is that each reading, control or event identifies a type. Because of the wide variety of data that can be captured by a smart meter, a system was needed to uniquely and unambiguously identify a description of each quantity, event or control being conveyed. In order to achieve this, each type is named by a string that is defined using a normative ‘dot’ notation, where each position within the dot string is used to describe some aspect of the quantity. In the case of reading types there are many factors beyond simple units of measure that factor into a quantity that is read by a meter, including but not limited to:
 Macro period, e.g. billing period, daily, monthly, seasonal, specified, …

Aggregate, i.e. is this an average, maximum, minimum, excess, etc.

Measuring period, e.g. a number of minutes, hours, interval,…

Accumulation, is this value a bulk quantity, cumulative, summation, instantaneous, etc.

Flow direction

Unit of measure
 Commodity, e.g. electricity, water, gas, co2, …

Measurement kind, e.g. frequency, energy, losses, voltage, angle, …

Time of use

Harmonics

Phase

Currency
 …
The following table describes a few commonly used reading types.

ReadingType name Description of ReadingType
0.0.0.1.1.1.12.0.0.0.0.0.0.0.0.3.72.0
8.8.53.6.1.1.8.0.0.0.0.0.0.0.0.3.38.0
0.0.2.4.1.1.12.0.0.0.0.0.0.0.0.3.72.0 bulkQuantity forward electricitySecondaryMetered energy (kWh) billingPeriod maximum fixedBlock15Min indicating forward electricitySecondaryMetered demand (kW) fifteenMinute deltaData forward electricitySecondaryMetered energy (kWh)
0.0.0.0.0.1.11.0.0.0.0.0.0.0.0.0.109.0
0.0.0.6.0.1.54.0.0.0.0.0.0.0.0.0.29.0
0.0.0.1.0.1.131.0.0.0.0.0.0.0.0.0.111.0 electricitySecondaryMetered energization (status) indicating electricitySecondaryMetered voltage (V) bulkQuantity electricitySecondaryMetered loadInterrupt (count)
0.0.2.4.1.1.12.0.0.0.0.0.0.0.0.3.72.0 fifteenMinute deltaData forward electricitySecondaryMetered energy (kWh)
Similarly, codes are defined for reading qualities, events and controls. A normative set of commonly used codes are defined in the Annexes of IEC 61968-9, as well as the information needed to define codes that currently have no normative definition. In all cases there is no expectation that the name (defined using the dot notation) be parsed by a receiving application, as the primary purpose of the name is to differentiate the different reading types while avoiding the ad-hoc definition of a set of likely ambiguous set of codes.
The IEC 61968-9 standard defines a number of message payload definitions that are used for the bidirectional communication of meter information within the enterprise. The payload of a message is the information of interest to a target application. These payloads are derived from the CIM in the form of XML Schemas (XSDs), and are often referred to as ‘CIM profiles’. There still needs to be a standard for the conveyance of these payloads between the systems using a variety of communications transports. For this reason, the IEC 6968-100 standard was developed. Given a message payload definition, IEC 61968-100 is used to define:

A common message envelope that can be used to convey the message payload

A standard header within the message envelope that describes the nature and control aspects of the message

A basic set of integration patterns that can be used to convey the messages

Recommendations for leveraging transport technologies such as (but certainly not limited to) web services and JMS
The following are four examples of integration patterns that are defined by IEC 61968-100, where an Enterprise
Service Bus (ESB) is leveraged for integration.

Depending upon the transport, these integration patterns might also be implemented without an intermediary such as an ESB. As anticipated, there are new transport mechanisms that are coming into use since the adoption of 61968-
100, where it is the intent not to preclude the use of these new transport mechanisms.
The following diagram describes the IEC 61968-100 message envelope. Depending upon the specific usage of a message within an integration pattern, the optional Request, Reply and/or Payload sections are used.
The Header is the required section of the message, where information such as an IEC 61968 verb, a noun (that describes the contents of the payload), a timestamp, the ID of the source and other information useful to the routing and processing of the message are provided. Upon receipt of a message, the receiver will typically examine the header to determine how the message should be processed. This provides opportunities for genericity of processing.
The following is an example message encoded using IEC 61968-9 and IEC 61968-100 to convey a meter event. In this case the message is published using the past tense verb ‘created’ to indicate that something has happened, and the noun identifies the type of the payload which in this case is an IEC 61968-9 EndDeviceEvent. Note the top level element in the payload section is the same as the noun.

<?xml version="1.0" encoding="UTF-8"?>
<ns0:EventMessage xmlns:SOAP-ENV= http://schemas.xmlsoap.org/soap/envelope/ xmlns:ns0="http://www.iec.ch/TC57/20011schema/message">
<ns0:Header>
<ns0:Verb> created </ns0:Verb>
<ns0:Noun> EndDeviceEvents </ns0:Noun>
<ns0:Revision>1</ns0:Revision>
<ns0:Timestamp>2009-11-04T18:52:50.001-05:00</ns0:Timestamp>
<ns0:Source>Metering System</ns0:Source>
</ns0:Header>
<ns0:Payload>
<ns1: EndDeviceEvents xmlns:ns1="http://iec.ch/TC57/2011EndDeviceEvents#">
<ns1:EndDeviceEventType ref=‘ 3.26.0.85
’>
<ns1:mRID>3dc53ee5-777e-50b4-8699-a1c224f45f3d</ns1:mRID>
<ns1:createdDateTime>2009-11-04T18:52:50.001-05:00</ns1:createdDateTime>
<ns1:description>Power off alarrm</ns1:description>
<ns1:severity>1</ns1:severity>
<ns1:Assets>
<ns1:mRID> 7a681339-facd-46be-b13e-3a8d70e30d50</ns1:mRID>
</ns1:Assets>
</ns1:EndDeviceEvent>
</ns1:EndDeviceEvents>
</ns0:Payload>
</ns0:EventMessage>
Also of interest in the preceding EndDeviceEvent message was the reference used for the EndDeviceEventType element. The string 3.26.0.85 is a code defined by IEC 61968-9 that indicates a power off alarm was detected and reported by a meter.
When integrating systems, there are a number of variables in play for the design of specific information exchanges.
The existence of a standard information model such as the CIM significantly reduces the number of variables, leaving the integration design to be more of a mechanical application of specific integration technologies, such as
(but certainly not limited to) XML and web services. The existence of the CIM and related standards such as IEC
61968-9 and IEC 61968-100 provide guidance to product vendors for the development and support of productized interfaces that can be used for integration. The existence of productized interfaces then can greatly simplify efforts related to systems integration, especially if source and target systems recognize a common set of standards, as would be the case when vendors leverage the CIM and related standards.
However it still needs to be recognized that not all products currently used within the smart meter landscape leverage the CIM and related standards. In those cases the CIM still provides significant value, as it defines a common, comprehensive target information model eliminating the need for other systems to understand proprietary representations of meter information.

The adoption of smart metering immediately confronts utilities with a huge increase in the volume of data associated with the core function of reading meters. Going from one reading per month to one every (say) fifteen minutes is roughly a three-thousand-fold increase.
There are several other aspects of “big data”, beside its sheer bulk, that push traditional enterprise information technology beyond its limits, thereby impelling investment in new technology and/or new business partnerships.
The foremost of these aspects is latency , or the interval of time between the initial capture of a datum and the initiation or completion of a business process that uses it.
The reduction in the latency of meter readings from thirty days to fifteen minutes is even more disruptive for utility business processes than the increase in volume. If consumers are told that a key benefit of smart metering is that more granular data will enable them to optimize their patterns of energy consumption, they will naturally wish to gain access to that information in a timely manner – which, naively, implies a latency on the order of the sample rate, rather than of 24 to 48 hours (much less a month).
Another problematic aspect of big data is the pervasive need for data from one source to be enriched with data from other sources. Meter readings, per se , are only a point of entry into the hugely expanded information landscape that comes with the adoption of smart metering, as set forth in Section I., above. Extracting the hidden value from meter data, for business or consumer decision support, involves enriching it with geographic, demographic, meteorological, and economic data from a range of sources both inside and outside the utility; and the resulting enriched data may be destined for consumption outside the utility as well.
In the absence of information standards, each of these enrichment scenarios would, at worst, involve its own implementation effort, with no reuse. The best possible scenario, with effective standardization of information, would be implementation effort proportional to the number of information classes, rather than to the number of interchange/enrichment scenarios.
Traditional enterprise data-consumption environments are centered around data warehouses, which are optimized for query, reporting, and analytics, primarily through the use of dimensional data models, rather than the relational data models used in transactional systems. An enterprise data warehouse imposes some degree of standardization on the data that it contains, in the process of extracting it from source systems. This does not reduce the development effort on the data extraction side, but potentially reduces it on the data-consumption (reporting, analytics) side.
Typically, data warehouses are populated by background processes that introduce latency on the order of hours to days, which may not meet the expectations of utility customers for timely decision support.
Basing a data warehouse on CIM would seem to be a comprehensive recipe for reuse and interoperability, but that promise awaits realization. The CIM UML model has been translated into relational and dimensional physical data models, but the results require far-reaching optimization for efficiency. The possible optimization strategies are infinitely variable and therefore require additional effort to achieve interoperability.
Where the utility’s own systems cannot provide either the new business semantics or the generally much shorter latencies that are associated with the leveraging of big data, it may be appropriate to outsource these functions to partners, rather than making large investments in new technology; but then the data has to be provided to the partners in some form.
The role of CIM in big-data scenarios is still, therefore, mostly the same kind of role as in application integration: as a standard representation of data-in-flight. The difference is that whereas, in an integration context, data-in-flight is primarily transactional and composed of standardized CIM messages, in analytics the data (both input and output) is

more likely to be bulk data and the particular enrichment requirements for each report or analytic may require CIM objects to be composed in unique ways.
Here are some examples of the kinds of ad-hoc compositions of CIM classes that may be required for utility analytics:

Data generated in the context of the meter-to-cash process may be analyzed for indications of energy theft, by correlating readings at specific usage points with expected averages and with customers’ payment and credit history.

Interval readings can be analyzed together with weather data, distribution grid loading, and history of all of these where available, to support load forecasting.

Complex patterns of meter events, combined with readings from environmental sensors and patterns of communications errors can be used to predict meter failure or to detect tampering.

Interval readings aggregated at the circuit level can be used to drive transactive-energy systems that implement real-time pricing or other demand-response programs.

The effectiveness of consumer energy-conservation programs can be assessed using much the same kinds of data as load forecasting.
CIM defines representations of all of these kinds of data (or ways to incorporate other standards, as in the case of weather data) at the class level. The various compositions of CIM classes required for each analytic algorithm would be too numerous and too specialized to themselves be candidates for standardization, but modelling and software development tools driven by the CIM UML model would allow the construction of libraries of components, corresponding to CIM classes, that could then be composed with consistent and predictable results.
There is an ever growing set of uses for smart meters and their information, far beyond basic customer billing. The
CIM provides the means to readily capture, correlate, maintain and communicate this information for current and future uses, where many future uses are yet unknown.