Sunday, 7 December 2014

Oracle Utilities Customer Care and Billing (CC&B) – Interval Billing Feature

Oracle Utilities Customer Care and Billing (CC&B) – Interval Billing Feature:


“Interval Meters” measure electricity usage in intervals, usually 30 - minutes or 15-minute periods. Oracle CC&B supports to upload such interval meter data and computes it for billing purpose.

C&I Customers are charged based on "Spot Market Pricing". They pay the more for electricity during peak hours of the day and pay less for electricity during the off peak hours. This is why it is important to understand interval data and be able to make informed decisions for load shifting and controlling the demand.

“Spot Market Energy Pricing” Changes from hour to hour, day to night, from season to season, and for short periods in response to high levels of demand or sudden changes on the grid. Customers with an interval meter are billed for their interval energy consumption against the interval price, which is set hourly or half-hourly by the Independent Electricity System Operators (IESO).

As demand increases, more expensive offers from generators are accepted, which raises the price of electricity. As demand drops, only the less expensive offers are accepted, which reduces the price. Customers are able to respond to changes in prices by shifting some of their demand to off-peak periods.



Oracle CC&B (interval Billing Module) can accept interval data and spot market energy price (interval Price) and computes them to bill the customer for their energy consumption.


The following steps illustrate the Interval meter reading and interval billing concepts in Oracle CC&B:

The configuration data setup for Interval Billing:

1.     Create Interval Profile Type:
·         Specify “Interval Data Creation” Algorithm
·         Specify “Interval Data Validation” Algorithm , if any


2.     Create Interval Profile Relation Type:
·         Add the Interval profile type created above

3.     Create Interval Register Type:
·         Add “Interval Register Validation” Algorithm, if any

4.     Create Bill Factor to upload Spot Price (Interval Price) Data:
·         Bill Factor Type should be “Interval”


5.     Create Bill Factor Characteristic to hold the Spot price values



6.     Rate Schedule:


7.     Rate version:

8.     Rate Component:
·         RC Type: should be “Interval Pricing”
·         Bill Factor: Attach the relevant Bill factor which contains spot/interval price data
·         Calc Algorithm: Attach the relevant interval price calculation algorithm (Note: Interval Billing will not have Bill Segment Type – Consumption Calculation Algorithm. Instead the Calculation algorithm on the Rate Component computes the Bill amount by multiplying the interval profile data by the spot/interval price.
·         Interval Profile Relation Type: This indicates profile linked to the SA which contains the interval quantities to be processed.

9.     Rate Component – Calc Algorithm configuration: (Note: “Data must be continuous” parameter to be set as “N”, if there are any gaps in interval data)


Master Data Setup:

1.     Create V-Setup (Person, Account, SA, Service Point, Premise):

2.     Create Meter Configuration - “Interval Flag” to be checked for Register(s).\

3.     Create Interval profile:
·         Specify Interval Profile Type created as above
·         Specify SA Id created as part of V-Setup

4.     Attach Interval Profile with SA created as part of V-Setup



5.     Upload Register Data using Process-X (Custom Batch Program) in the following tables.
·         CI_REG_DATA_SET
·         CI_REG_DATA

Register Data Set: (Created for 10 days – 01-JAN-2014 till 10-JAN-2014) 


Register Data: (Created for 10 days – 01-JAN-2014 till 10-JAN-2014)
 


6.     Run Base Product Batch Program IREGIDB (Determine register for datasets). This will populate Register Id in CI_REG_DATA_SET using External Id


7.      Run Base Product Batch Program IREGDVB (Interval register data validation). This process is used to validate interval register data and complete register data set; the validation algorithms attached to the “Interval Register Type” will be executed when this batch is run.

8.     Run Base Product Batch Program IB-SPDB (Interval data set derivation). This process derives interval data for accounts in the system.  Only accounts that have at least one interval SA with derivable profiles linked to it are processed.  A 'derivable' profile is an SA Owned profile where this SA is the owner AND the profile type indicates an "Interval Data Creation" derivation algorithm.  Interval data for SAs linked to the Account are derived in Process Priority order as defined on their SA Type.  For each SA, the Interval Data Creation algorithms are executed in creation priority order. Custom interval data derivation algorithms can also be written based on the business need. This will populate interval data in the following tables:
·         CI_INTV_DATA_SET
·         CI_INTV_DATA

Interval Data Set: Created for 10 days (01-JAN-2014 till 10-JAN-2014)

Interval Data: Created for 10 days (01-JAN-2014 till 10-JAN-2014)






9.     Run Base Product Batch Program IPDSDVB (Interval profile data validation). This process is used to validate interval profile data.  It processes interval profiles that were created up to the cutoff date/time and executes their validation algorithms, if any, defined on their profile type. The algorithms are executed one after the other in their predefined sequence order.

10.  Upload Spot/Interval Price using Process-X (Custom Batch Program) in the following tables. This is used to populate the spot price data into the Bill Factor – which is configured in the rate component for interval billing.
·         CI_INTV_VAL_SET
·         CI_INTV_VAL
   Interval Value Set: Created for 10 days (01-JAN-2014 till 10-JAN-2014)
   


   Interval Value: Created for 10 days (01-JAN-2014 till 10-JAN-2014)


11.  Create bill for the account for 01-JAN-2014 till 10-JAN-2014

      ·         Bill:


·         Bill Segment Calc Line:


·         Interval Pricing – Calculation Detail (Note: This will be available only if an “Audit Algorithm” plugged on the Rate Component)

Key Notes:

  •         If multiple data/set available for a specific date/time, Base package interval data derivation (IB-SPDB) process will make use of the latest register data/set for derivation. The older register data/set will NOT be used for interval data derivation process.
  •         If non consecutive register data is uploaded, Base package interval data derivation (IB-ISDB) process will create “error” data set, as it expects the data to be continuous. IB-SPDB will not expect interval data for valid Gaps (ie, Gaps due to Meter or SP/Meter removal). Even if register data is received for valid Gap period (Meter removal, SP removal) then IB-SPDB will not consider them for derivation. Such register data will be ignored.
  •           During Interval data derivation, if there are any Invalid Gaps found in the register data, then Interval derivation algorithm will not use the subsequent register data for derivation.
  •          If one or more Bill Factor - Spot Price intervals are missing, Bill generation will  fail regard less of Rate component algorithm parameter (Data must be continuous = Y/N)
  •           If multiple Spot price values available for a same date/time, then Rate Component-Calculation algorithm will consider the latest interval value set for Bill amount computation.
  •           If Rate component algorithm parameter “Data must be continuous” is set as “Y”, System expects continuous interval data to be available (excluding valid Gaps due to Meter or SP/Meter removal) for the entire bill period. Otherwise, Bill generation will fail.


Thursday, 30 October 2014

Oracle Utilities Meter Data Management – The backbone for Smart grid implementations



Summary

The Meter Data Management industry has emerged as one of the keys to Smart Grid implementations all over the world. Meter Data Management systems provide the ability to manage, store and process consumption data. It is a crucial element of operating the smart grid as well as creating the value added services that lead to consumer efficiency and economic viability.

This White paper explores the influence of Oracle Utilities Meter Data Management system on a Smart Grid vision, goals, objectives and implementation. As utilities try to optimize their operations by deploying new smart grid technologies, Oracle MDM becomes a vital component in envision their smart grid objectives.  This paper analyzes Oracle MDM state of art technology drivers and its core features to take an integrated approach to meet smart metering requirements and present the factors that contribute to an enterprise platform strategy so that utilities companies can fulfil Smart Grid potential and make more informed technology decisions down the line. This white paper is derived from the wealth of information pertaining to Oracle utilities product operational, implementation and administration manuals and various smart grid implementation case studies.

Systems around a Smart Grid Implementation

It is important to understand the participating systems around the Smart Grid spectrum. These systems play major role in any successful smart grid implementations.

Smart Grid

Smart Grid integrates new innovative tools and technologies from generation, transmission and distribution all the way to consumer appliances and equipment. It provides capabilities in monitoring, controlling, optimizing the efficiencies and automating the entire energy delivery grid. Implementation of a Meter Data Management, Advanced Metering Infrastructure, Distribution Management Systems and other systems provide the information and control necessary to manage the operation and improve the overall efficiency of the smart grid.

The major benefits of a smart grid implementation largely rely on effective data collection and establishment of efficient commutation between AMI infrastructure and the utility systems.  Meter data management systems store and analyze the meter level activities and consumption data, providing a foundation for any Smart Grid implementation.

Head End System

Head end system is a critical component of the AMI network. It is typically hosted within the utility data centre and its primary responsibility is to manage communications with the AMI network of meters and data concentrators in the field. The Head End System is designed to be a real time control and monitoring console for the AMI network, and it passes data between smart devices and the utility. Head End Systems typically consist of server hardware, software applications and database to perform the following functions:

       Meter data acquisition and collection.
       Commissioning and decommissioning of meters and utility services.
       Data concentrator status monitoring.
       Meter configurations and parameters setup.
       On demand meter reading and device check requests.
       Firmware upgrades of the smart devices

Advanced Metering Infrastructure (AMI)

AMI consists of both advanced meters and the supporting field networks that control and manage meters. It makes use of various networking models to establish communication with the smart meters in the field.

Meter Data Management (MDM) System

MDM system collects, validates and persist advanced meter data that can be used by the various utility systems such as bill­ing, outage management and geographical information systems.  It permanently stores meter data and uses business rules to transform them into billable usage. The Customer Information Systems can make use of these usage data to bill their customers. It provides a single repository for the data with a various analysis capabilities and facilitates the integration with other utility systems.  The benefits of meter data management systems spread across the Smart Grid lifecycle, from project planning to deployment to system operations and maintenance.

Smart Meter

Smart Meter is the advanced meter that enables communication between the customer and service provider, allowing both to better managing their power usage. While the customer gets up to date infor­mation about their consumption data, the utilities are able to detect unusual consumption patterns, power status information and power quality monitoring. Smart Metering is an essential information source that drives enterprise efficiencies and benefits the distribution business.

Demand Response

Demand Response encourages consumers to reduce their demand, particularly during peak load periods. Demand response programs are achieved by increased customer energy usage awareness, modern technologies and new rate struc­tures such as smart thermostats, in-home displays, critical peak price alerts, real-time pricing, time-of-use and interruptible rates. Demand Response leads to reduction of consumer energy usage, increases system reliability, and supports infrastructure op­timization. It can potentially defer the utility’s investment in energy generation.

Smart Grid Applications

These are utility applications that use advanced meter data to improve and expand functionality. Smart Grid applications include enhancements to existing applications with data from advanced meters as well as entirely new applications made possible by advanced meter data such as Outage Management Systems (OMS), Market Settlement applications, and Distribution capacity planning systems.

Importance of Oracle Meter Data Management System:

A large number of utilities are implementing and leveraging smart metering technologies. One of the primary consequences of implementing smart metering technology is that it results in a flow of huge volume of meter data much greater than traditional manual metering systems where the meter data is collected on a bimonthly, monthly or quarterly basis.

This increased data volume will flow into the utility which manages the distribution system and also be passed to and from third-party retailers for processing under new market transactions. Utilities implementing Smart Metering programs face the challenge of managing the huge volume of meter data and transform them into business requirements. To meet these challenges Oracle Meter Data Management system provides utilities with a business critical solution for storing, validating, aggregating and processing large volumes of meter data and preparing them for billing, settlements, analysis and other reporting needs.

For example, consider an electric utility with 1 million smart meters where each meter sends its measurements 3 times a day will have 3 million measurements each day. Each measurement is subject to validation, editing (if they are obviously wrong), and estimation (if they are missing).  Assume if a meter configured to measure 15 minute intervals will have roughly 2,880 measurements each month. So, 1 million such devices results in 2,880,000,000 (i.e., 2.88 billion) measurements each month. The normalized meter data is periodically transformed into more concise and palatable usage data. This usage data is then made available for the subscribing systems. For example, if a CIS system subscribes to time-of-use totals based on peak, off-peak and shoulder peak categories, it would receive only the aggregated 3 million usage data per month rather than 2.88 billion measurements.

Oracle Meter Data Management system is built with it state of art software and hardware platforms to handle such a huge volume of flooding data in a more efficient way.  Figure - 1 illustrates Oracle MDM architecture including its touch points with upstream data collection systems and downstream enterprise systems.

(Figure -1)


                                               




Oracle Utilities Meter Data Management system core features:

The rest of this paper discusses in detail about the core features of Oracle Meter Data Management system and its role in smart grid implementations.

Master Data Synchronization:

Oracle MDM does not own meter, service point, premise and customer contact information. These are called master data and need to be made available to MDM to be operational. A set of data synchronization processes brings these data from the respective data owner systems into Oracle MDM. For example, a utility using Oracle CC&B, the customer and meter information would be synchronized into MDM through the synchronization process.  Similarly, any information captured from the field using head end systems will need to be synchronized back to the respective systems.

Oracle MDM uses “Initial Sync” process, a set of batch process activities to copy required master data information from CC&B into MDM. This would typically be carried out during the production migration time of the smart metering implementations. Once the system goes live, the new master data and the filed updates are synchronized using “On-going Sync” process. For example, a new customer enrolled in CC&B system should be added to MDM system as and when required using this process.

Oracle MDM being the system of record for the meter data information collected from the head end systems, the remaining master data required for its operation would be synchronized to and from the participating systems. Data synchronization process ensures that customer information is correctly associated with the proper meter data in a timely manner. Oracle productized integration pack for CC&B – MDM automates the data synchronization process and helps the utilities to reduce the integration complexity and implementation time.

Validation, Editing and Estimation (VEE):

One of the most important functions of Oracle MDM system is the data cleansing process. This is commonly referred as Validation, Editing and Estimation (VEE) process. Oracle MDM contains a wide range of pre configured VEE rules to process the consumption data received from data collection systems on bimonthly, monthly or quarterly basis as well as the interval data received from modern AMI systems.

Though Oracle MDM supports a number of widely used industry standard VEE rules out of the box, it also provides users with the ability to easily create any custom validation and estimation rules for a variety of purposes. It requires minimal configuration or programming and scripting to create such special rules with very less cost and time associated with system deployment and operations. Oracle MDM allows the user to create different VEE rules for different types of meter registers and based on what the meter measures. The below is the list of pre configured VEE rules supported by Oracle MDM.

·         Interval Adjustment From Scalar  
·         Interval Averaging Estimation  
·         Interval Interpolation Estimation  
·         Interval Profile Estimation
·         Scalar Estimation  
·         Scalar Profile Estimation
·         Interval Size Validation  
·         Interval Spike Check  Validation
·         Sum Check  Validation
·         Unit Of Measure Check  
·         High/Low Check  
·         Zero Consumption Check   
·         Negative Consumption Check  
·         Interval Missing Quantity Check 
·         Channel / Register Multiplier Check  
·         Scalar Calculation From Interval  
·         Scalar Replacement Rule 
·         Interval Replacement Rule  

VEE rules are often driven by the regulatory bodies in different geography. There may be more complex VEE requirements imposed in a deregulated market area where data need to be delivered to multiple market participants. Oracle MDM uses more complex VEE rules to process the interval data than the scalar data received from the manual collection systems. It can support different VEE work flows for different jurisdictions, geography, service type or customer type based on specific criteria as well.

Oracle MDM makes use of the customer measurement profile feature for the estimation process where they can fill in missing data with the appropriate values based on the profiles.  The system considers utilities requirements and overall business processes and decides under what circumstances data are automatically estimated, and under what circumstances should there be manual intervention and how are the exceptions generated and handled. Oracle MDM demonstrates significant flexibility in order to maximize effectiveness of the use of VEE component.  Similar set of VEE rules can be grouped together and can be reused in different places. A different set of VEE rules can be applied for the measurement data received from head end system, the estimated data and manually created measurements based on certain criteria.

Measurement and Billable Usage

In the past, utilities were collecting the measurements on monthly or quarterly basis. With the advent of Smart Grid applications utilities are collecting interval data on a possible smallest interval periods. For example, a utility having 1 Million commercial and industrial electric meters with 15 minutes interval would collect 2,880,000,000 (i.e., 2.88 billion) measurements each month. So, Oracle MDM becomes the key for handling this huge volume of data generated by the smart meters.

Oracle MDM enables loose coupling between systems. Multiple AMI systems can send their data via their respective head end systems to Oracle SGG (smart Grid Gateway), where the data is unified and queued to be processed by Oracle MDM system. Once the measurements are received, Oracle MDM will run the VEE processes to create a clean bill ready measurement data. This process will also fill any gaps (for the missing data) based on the VEE configurations. Downstream utility systems such as Billing Systems, Data Warehouse Systems and Outage Management Systems can subscribe their data from the Oracle MDM for their specific purposes.

For example, Oracle Customer Care & Billing system can obtain billable usage data for interval and scalar meters from Oracle MDM without worrying about which AMI system collected the measurement data from the customers. This service oriented architecture creates a virtual plug and play capability and ensures the flexibility during system upgrades or change of any sub systems with minimal cost, disruption and effort.

Delivering Bill-Ready Meter Data:

Oracle MDM manages interaction among different data collection technologies and provides information to billing system upon request. For example, Oracle CC&B initiates requests for billing data based on specific billing cycle or on demand off cycle business processes. Oracle MDM is responsible for interpreting the CC&B usage request and forwarding it to the appropriate AMI system if necessary. Finally it returns the response back to CC&B. In this case, Oracle CC&B manages the cash flow of the utility, determining when and how customer consumption data are converted into billing information.

With Productized integration pack, Oracle MDM can be configured to push the usage data to CC&B at the end of every measurement cycle and letting CC&B make use of the usage data for billing purpose.  On the other hand, CC&B can also be configured to pull the usage data from Oracle MDM during bill cycle. To deliver bill-ready data Oracle MDM normalizes the raw measurement data received from the AMI system into billing determinants and delivers service point level billable usage to the CC&B.

Smart Grid Gateway – Two Way Communication and Process Automation

Oracle provides a range of Smart Grid gateway (SGG) adapters to integrate multiple AMI systems that use different technologies, protocol and data formats to share meter data with other systems. This feature effectively decouples downstream applications from Advanced Metering Infrastructure. It also allows the integration of new technologies as they emerge, and the decommissioning of old technologies, without being restricted to a single vendor or AMI implementation. This means consumers can use Oracle MDM as a single consistent interface across the various AMI systems with data presented in a centralized repository.

To enable utilities to deal with multiple AMI systems, Oracle MDM abstracts the business process from specific implementation details. Each Head End System vendors may implement their AMI systems using CMI, Multispeak, IEC 61968 or any other vendor specific proprietary interfaces. Oracle SGG provides abstraction from vendor specific interfaces and acts as a data communication bridge in the overall enterprise architecture ensuring flexibility and extensibility throughout the life of Smart Metering programs.



Oracle MDM categorize the device events send by the different Head End Systems into standardized event types.  Oracle has delivered productized SGG adapters for Landis+Gyr, Echelon, MV90, Sensus RNI, Silver Spring Networks and Itron OpenWay Head End Systems. Utilities can also make use of Oracle Application Development Kid (ADK) to build the integration layer for any other Head End Systems.

Oracle MDM plays a vital role in enabling bi-directional smart metering infrastructure networks to communicate with other systems. It provides routing and management components for implementing the required two-way processes. Oracle MDM is capable of handling the following smart metering commands with Oracle SGG:

·         Remote Connect - Initiates power flow from the source through the meter. This does not mean that the device is being installed. Once command is being sent, it is assumed that the device has already been installed. The Head End Systems typically require more than one communication to facilitate this process. Utilities may also want to retrieve a start read for scalar subtractive meters during this command.
·         Remote Disconnect - Stops power flow through the meter. This does not mean that the device is being removed. Like connect command, disconnect typically involves more than one communication to the Head End System. Utilities may want to retrieve an end read for scalar subtractive meters during this command.
·         Device Commissioning - Drives the registration or discovery of the device by the Head End System. This process does not always require an explicit communication. Utilities won’t always receive an explicit response to a commission request. Sometimes receiving measurements could be an indication of a successful commissioning.
·         Device Decommissioning - Notifies the Head End System that no further data will be arriving from the device
·         On Demand Read (Interval) - Accommodates near real time requests for readings.
·         Device Status Check (Meter Ping) - Returns the working condition of a device, and this might involve more than one communication.

The Smart metering commands can be enabled by end to end process automations. For example, an utility using Oracle CC&B and MDM systems could include the integration of “turn-on/turn-off” business process by combining both manual collection method and smart meters with an integrated remote connect disconnect command. In this case, once CC&B system determines that customer power is to be turned off, Oracle MDM system can be implemented to determine, depending on the meter type, whether the turn-on/turn-off requires a field service order, or can be executed directly through the smart metering infrastructure systems using the SGG smart metering commands.

Oracle SGG benefits the customer by reducing costs to implement and operate smart grid processes and programs, minimizes data duplication and improves system performance, provides a common set of commands to foster application interoperability and improves the security and better audit of smart grid processes.

Smart Meter Events

Smart meters are capable of detecting and producing various events to alert a utility that something significant has happened to it, such as an attempt to tamper with the device, a loss of power, or that the device has a low battery indicator. While loading a device event, the Oracle MDM first determines from which Head End System the event is received and then finds out which device produced it. Based on the Head End System that sent it, the system finds the standard event type that corresponds to the event sent.  Oracle MDM then determines if any additional processing is needed for the event. For example, some events might arrive in pairs (power outage and power restoration) are handled differently than singular events. External applications can subscribe to receive events of certain categories. After events have been analyzed and stored, they are sent to the subscribing application using the business process defined for the subscriber.


The below is the list of standard events supported by Oracle MDM system. Any new event categories can also be configured using the custom extensions.

  • Low Battery Detected
  • Low Voltage
  • Magnetic Tampering          
  • Power Outage - (Last Gasp)          
  • Poor Power Quality          
  • Power Restoration
  • Reverse Rotation          
  • Momentary Outage
  • Tamper Alert
      

Time of Use (TOU) Based Usage and Billing

Smart meters are capable of measuring the interval data. They are configured to records energy consumption of a customer at a defined regular interval (For example, every 60, 30 and 15 minutes). Oracle MDM has the ability to define TOU (Time of Usage) code configuration to denote on peak, shoulder peak and off-peak consumption. Using the TOU mapping, the interval consumptions are accumulated under the respective TOU category. 


 
Utilities make use of TOU pricing to reflect the cost of electricity supply. Prices in the market can rise and fall during a day based on demand and the type of supply available. When demand is lower, less expensive sources of electricity are used. When demand rises, more expensive forms of electricity production are called upon. TOU prices take into account when as well as how much electricity a consumer uses as recorded by the consumer’s smart meter. 



TOU prices are designed to encourage consumers to shift energy use from high price periods (on peak) to lower price periods (shoulder peak and off peak).  They are developed as part of the Regulated Price Plan (RPP) for those with smart meters. Oracle MDM provides the utilities as many as different views of the Time of Use Data for their analysis and decision making processes.

The below pictographs shows Oracle MDM capability to analyze the energy consumption pattern of a customer with respect to different time of use codes and seasons (on-peak winter, off-peak winder, shoulder peak winter and holiday). The energy consumption with respect weather pattern (temperature data) of the customer’s geography also compared and analyzed.


Critical Peak Period (CPP): Using Oracle MDM normal TOU map could be overridden by a dynamic TOU map option to handle Critical Peak Period situations. A different pricing can be applied for such TOU periods. The utility could have a program that credits customers for conservation during critical peak periods. A consumer receives a credit for consumption during a CPP event that is lower than their "normal" consumption.


Demand Response (DR): The utility could have a program where customers can optionally participate in demand response programs. The utility can declare a DR event for any upcoming time span. When a DR event starts, the system sends smart meter messages to turn off the customer's equipment. When the DR event concludes, the system sends another smart meter message to turn on the customer's equipment. The utility would like to measure the amount of consumption conserved during these events.

Net Metering / Net Energy Metering

Net Metering allows a customer (energy generator) to receive a financial credit for power generated by their onsite system and fed back to the utility.  The credit is used to offset the customer's electricity bill.  Net energy metering is an important element of green energy policy framework supporting direct customer investment in distributed renewable energy generation.

Distributed generation programs allows homes and businesses to generate their own power from renewable sources such as wind, water, solar and agricultural biomass and distributing any excess electricity back to the grid. An electrical converter called an inverter turns the DC (direct current) power coming from your renewable energy source into AC (alternating current) power, which matches the voltage of the electricity flowing through the power line. The excess energy is being generated can be recorded by the power meter, giving credit to a customer.  Oracle MDM is a vital application to provide benefits to Demand Response and Distributed generation programs as it meets the business drivers include billing, customer service and efficient analysis through the below features.

  • Meter Channel - The ability to record and store at least two channels of energy interval data, Consumed energy from the Utility the Generated energy by the consumer.
  • Net metering - Consumer is billed for net energy use during the various tiers.
  • Sophisticated validation and estimation routines - Account for energy imports from customers, also accommodate negative net energy usage in an interval.
  • The ability to perform “net usage” functions - The consumer is compensated for energy delivered onto the grid using a separate generation tariff.

Benefits of net metering

  • The system is easy and inexpensive. It enables people to get real value for the energy they produce without having to install a second meter or an expensive battery storage system.
  • It allows homeowners and businesses to produce energy which takes some of the pressure off the grid, especially during periods of peak consumption.
  • Each home can potentially power two or three other homes. If enough homes in a neighbourhood use renewable energy and net metering, the neighbourhood could potentially become self reliant.
  • It encourages consumers to play an active role in alternative energy production, which both protects the environment and helps preserve natural energy resources.
  • Homes that use net metering tend to be more aware of and therefore more conscientious about their energy consumption.
  • It saves utility companies money on meter installation, reading and billing costs.


Oracle MDM uses Measuring Components (MC) to map the smart meter registers (channels) with the following characteristics to identify what it actually measures.
·         Unite Of Measure (UOM) – What is measured by the register.
·         Seconds per Interval (SPI) – The interval (15 or 30 or 60 min).
·         Service Quantity Identifier (SQI) – Generated or Consumed.

An SQI is used when multiple measuring components measure the same thing, but in different ways. For example a meter that measures both generation and consumption. A smart meter capable of measuring the consumption and generation of energy can send data to Oracle MDM, and get stored in the meter data repository. This data can be made available to downstream applications for billing computation and analysis purpose.

If the customer has generated more energy than used, at the end of the year, the electric company may pay back for the extra power at the retail rate. Net metering can be measured over the month or year. Annualized net metering provides a more accurate measurement because it takes into account your changing energy usage and production over the four seasons.

Exception Monitoring, Reporting and Analytics


In addition to consumption data, Oracle MDM can also receive events, status messages, alarms and alerts from AMI systems to provide real time monitoring of the network and field devices. The information provided can generate insight into operational issues, the health of devices and analysis of operational trends. Utilities may make use of these operational reports to dispatch meter technicians to the field and review trends that may indicate quality issues with a particular device.

If the data stored with in MDM properly analyzed and correlated with other information, it can provide a wealth of actionable insights. Oracle Utilities MDM Analytics make use of the measurement and event data and creates enterprise data warehouse to generate various historical, operational and business analytics reports and graphs. These reports include:

       Load forecasting by time of day, seasonal weather, areas, customer types, etc.
       Projecting weather or climate forecasts as related to usage patterns.
       Consumption by time of usage to inform load-shifting programs.
       Instantaneous outage and tampering information, including “last gasp” notifications.
       Identifying anomalies in consumption patterns that may indicate theft or other losses.
       Long term forecasting of demand supply requirements.
       Consumption at empty or vacant premises.
       Zero or very low consumption at occupied premises.
       Field crew reported problems (fraud/damage/blocked meters/dangerous situations, etc)
       Meter communication failures (In case AMI meters).

Conclusion

Utilities across the world are fulfilling key components of their smart grid initiatives by rolling out Smart Metering, AMI systems, MDM and CIS systems. These systems are designed to support and enable end to end business processes of utilities. While each utility will have varying business drivers, they will all share the need to maximize the return on their investment as quickly as possible. Oracle MDM enables utilities with multiple meter data collection technologies to bridge the technology gap between old and new technologies to deliver better customer service and optimize revenues with new smart metering roll out. The availability of pre built productized integrations between other Oracle utilities products enables the utilities to quickly realise the benefits of their smart grid pilots and implementations. Oracle MDM being the centralized repository for the meter and event data, Oracle Utilities analytics applications can easily access these data for operational and historical analysis. Finally, the importance of Oracle MDM depends on utilities priorities and the capabilities they need to add to achieve their Smart Grid vision.

About the author

Senthilkumar Manipillai is working for Oracle Utilities, India, has expertise in consulting and supporting various gas, electric and water utilities in Smart Grid and Smart metering implementation initiatives. His 15+ years of experience includes product development, project implementation and consultation for water and electric utilities in Europe, US and APAC regions. He holds MSc degree in Computer Science and is a certified Oracle Meter Data Management and Customer Care &Billing implementation specialist.