Oracle Utilities Smart Grid Gateway

Configuration Guide

Release 2.0.0 Service Pack 9

E20535-07

May 2013

Oracle Utilities Smart Grid Gateway/Smart Grid Gateway Installation and Configuration Guide, Volume 1, Release 2.0.0 Service Pack 9

E20535-07

Copyright © 2011, 2013 Oracle and/or its affiliates. All rights reserved.

Primary Author: Lou Prosperi

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this software or related documentation is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS

Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications which may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Overview

This chapter provides an overview of this configuration guide and an introduction to the Oracle Utilities Smart Grid Gateway application. This includes:

•

What Is This Book?

•

Architecture Overview

•

Oracle Utilities Application Framework Configuration Tools

•

Configuration Process Overview

What Is This Book?

This guide describes how to configure Oracle Utilities Smart Grid Gateway. It is intended for implementers and system administrators responsible for configuration and initial setup of the application.

Oracle Utilities Smart Grid Gateway is based on the Oracle Utilities Application Framework (OUAF). For information about using and configuring basic Framework functions, see the Oracle Utilities Application Framework documentation. This guide only covers configuration of functions specific to Oracle Utilities Smart Grid Gateway.

The body of this guide presents conceptual information to help you understand how the system works as well as how the various configuration options affect system functionality. Once you have an understanding of the system's capabilities, you can plan your data setup and design any customizations you want to implement.

When you are ready to implement your design, use the Admin Setup Reference Tables in Chapter 3 : Setting Up Admin Data to guide you through the setup process of admin data. This section lists each object that can be configured, defines any prerequisites for configuration.

Note : The sequence in which you configure system objects is very important. Admin Setup Reference Tables describes admin data dependencies and defines the order in which admin objects should be configured. By following this sequence carefully, you can streamline the configuration process and reduce the amount of time required for setup.

This guide includes the following chapters:

•

Chapter 1 : Overview (this chapter) provides an overview of the Oracle Utilities Smart Grid Gateway architecture and of the configuration tools and process used in implementing the product.

•

Chapter 2 : General Configuration provides an overview of some general configuration options used by the system.

•

Chapter 3 : Setting Up Admin Data describes the different types of admin data that must be set up and defined as part of implementing and configuring Oracle Utilities Smart Grid Gateway.

•

Chapter 4 : Devices, Measuring Components, and Device Configurations provides an overview of devices and measuring components and how they are used in the system, along with technical details concerning device-related maintenance and business objects.

•

Chapter 5 : Service Points and Device Installation provides an overview of service points and device installation-related objects and how they are used in the system, along with technical details concerning related maintenance and business objects.

•

Chapter 6 : Measurement Data provides an overview of initial and final measurement data and how it is used in the system, along with technical details concerning related maintenance and business objects.

•

Chapter 7 : Device Communication and Device Events provides an overview of the device communication-related objects and how they are used in the system, along with technical details concerning related maintenance and business objects.

•

Chapter 8 : Batch Processing provides a list of the base package batch controls provided with the system.

•

Chapter 9 : Integrating Oracle Utilities Smart Grid Gateway with Other Systems provides a description of how Oracle Utilities Smart Gird Gateway can be integrated with other systems.

•

Chapter 10 : Sample Implementation provides a high-level description of a sample implementation.

•

Chapter 11 : Smart Grid Gateway Adapters provides a description of the components included in Oracle Utilities Smart Grid Gateway adapters.

•

Appendix A : Glossary is a list of commonly used terms.

•

Appendix B : Base Package Data Areas provides lists of base package configuration objects that can be leveraged during an implementation.

Other Documentation

This section describes other documentation provided with Oracle Utilities Smart Grid Gateway.

Installation Documentation

Installation documentation describes the steps involved in the installation and initial set up of the system, and includes the following documents:

•

Oracle Utilities Smart Grid Gateway Quick Install Guide

•

Oracle Utilities Smart Grid Gateway DBA Guide

•

Oracle Utilities Smart Grid Gateway Installation Guide

User Documentation

User documentation provides conceptual information and procedures related to working with the various objects used in the system, and includes the following documents:

•

Oracle Utilities Application Framework Business Process Guide

•

Oracle Utilities Application Framework Administration Guide

•

Oracle Utilities Service and Measurement Data Foundation User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr User’s Guide

•

Oracle Utilities Smart Grid Gateway MV90 Adapter for Itron User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Echelon User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Sensus User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Silver Springs Network User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter Development Kit User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Itron OpenWay User’s Guide

Adapter Configuration Documentation

Adapter configuration documentation provides technical information related to vendor-specific Smart Grid Gateway adapters, and includes the following documents:

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr Configuration Guide

•

Oracle Utilities Smart Grid Gateway MV90 Adapter for Itron Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Echelon Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Sensus Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Silver Springs Network Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter Development Kit Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Itron OpenWay Configuration Guide

Supplemental Documentation

Supplemental documentation provides technical information related to system administration tasks and include the following documents:

•

Oracle Utilities Smart Grid Gateway Server Administration Guide

•

Oracle Utilities Smart Grid Gateway Batch Server Administration Guide

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus (OSB) and Oracle Business Process Execution Language (BPEL) as middleware components. These tools are part of the Oracle SOA Suite. See the Oracle SOA Suite Documentation library (http://www.oracle.com/technetwork/middleware/soasuite/documentation/index.html ) for more information about using these tools.

Embedded Help

Oracle Utilities Smart Grid Gateway, like all Oracle Utilities Application Framework applications, provides extensive internal documentation. For example, detailed descriptions of system objects are included in the objects' maintenance portals. The lifecycle of each business object is described on the Lifecycle tab and depicted in flow diagrams on the Summary tab. This information is extremely useful for implementers and system administrators.

Embedded help is provided for all non-obvious fields in most portals and zones. If a field has associated help text, a ? icon appears next to the field when the zone is displayed.

Online Help

Oracle Utilities Smart Grid Gateway also include context-sensitive help for all the user interface screens users will typically work with as they use the system. Online help contains conceptual information and procedures related to working with the various objects used in the system.

The online help is divided into the following three sections:

•

Oracle Utilities Application Framework: Describes the features and functions of the application framework (F1)

•

Oracle Utilities Service and Measurement Data Foundation: Describes the features and functions provided in the Service and Measurement Data Foundation (D1)

•

Oracle Utilities Smart Grid Gateway Adapters: Describes the features and functions provided in the smart grid gateway adapters (D3, D4, D5, etc.)

Other Documentation

This section describes other documentation provided with Oracle Utilities Smart Grid Gateway.

Installation Documentation

Installation documentation describes the steps involved in the installation and initial set up of the system, and includes the following documents:

•

Oracle Utilities Smart Grid Gateway Quick Install Guide

•

Oracle Utilities Smart Grid Gateway DBA Guide

•

Oracle Utilities Smart Grid Gateway Installation Guide

User Documentation

User documentation provides conceptual information and procedures related to working with the various objects used in the system, and includes the following documents:

•

Oracle Utilities Application Framework Business Process Guide

•

Oracle Utilities Application Framework Administration Guide

•

Oracle Utilities Service and Measurement Data Foundation User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr User’s Guide

•

Oracle Utilities Smart Grid Gateway MV90 Adapter for Itron User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Echelon User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Sensus User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Silver Springs Network User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter Development Kit User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Itron OpenWay User’s Guide

Adapter Configuration Documentation

Adapter configuration documentation provides technical information related to vendor-specific Smart Grid Gateway adapters, and includes the following documents:

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr Configuration Guide

•

Oracle Utilities Smart Grid Gateway MV90 Adapter for Itron Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Echelon Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Sensus Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Silver Springs Network Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter Development Kit Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Itron OpenWay Configuration Guide

Supplemental Documentation

Supplemental documentation provides technical information related to system administration tasks and include the following documents:

•

Oracle Utilities Smart Grid Gateway Server Administration Guide

•

Oracle Utilities Smart Grid Gateway Batch Server Administration Guide

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus (OSB) and Oracle Business Process Execution Language (BPEL) as middleware components. These tools are part of the Oracle SOA Suite. See the Oracle SOA Suite Documentation library (http://www.oracle.com/technetwork/middleware/soasuite/documentation/index.html ) for more information about using these tools.

Embedded Help

Oracle Utilities Smart Grid Gateway, like all Oracle Utilities Application Framework applications, provides extensive internal documentation. For example, detailed descriptions of system objects are included in the objects' maintenance portals. The lifecycle of each business object is described on the Lifecycle tab and depicted in flow diagrams on the Summary tab. This information is extremely useful for implementers and system administrators.

Embedded help is provided for all non-obvious fields in most portals and zones. If a field has associated help text, a ? icon appears next to the field when the zone is displayed.

Online Help

Oracle Utilities Smart Grid Gateway also include context-sensitive help for all the user interface screens users will typically work with as they use the system. Online help contains conceptual information and procedures related to working with the various objects used in the system.

The online help is divided into the following three sections:

•

Oracle Utilities Application Framework: Describes the features and functions of the application framework (F1)

•

Oracle Utilities Service and Measurement Data Foundation: Describes the features and functions provided in the Service and Measurement Data Foundation (D1)

•

Oracle Utilities Smart Grid Gateway Adapters: Describes the features and functions provided in the smart grid gateway adapters (D3, D4, D5, etc.)

Other Documentation

This section describes other documentation provided with Oracle Utilities Smart Grid Gateway.

Installation Documentation

Installation documentation describes the steps involved in the installation and initial set up of the system, and includes the following documents:

•

Oracle Utilities Smart Grid Gateway Quick Install Guide

•

Oracle Utilities Smart Grid Gateway DBA Guide

•

Oracle Utilities Smart Grid Gateway Installation Guide

User Documentation

User documentation provides conceptual information and procedures related to working with the various objects used in the system, and includes the following documents:

•

Oracle Utilities Application Framework Business Process Guide

•

Oracle Utilities Application Framework Administration Guide

•

Oracle Utilities Service and Measurement Data Foundation User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr User’s Guide

•

Oracle Utilities Smart Grid Gateway MV90 Adapter for Itron User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Echelon User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Sensus User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Silver Springs Network User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter Development Kit User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Itron OpenWay User’s Guide

Adapter Configuration Documentation

Adapter configuration documentation provides technical information related to vendor-specific Smart Grid Gateway adapters, and includes the following documents:

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr Configuration Guide

•

Oracle Utilities Smart Grid Gateway MV90 Adapter for Itron Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Echelon Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Sensus Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Silver Springs Network Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter Development Kit Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Itron OpenWay Configuration Guide

Supplemental Documentation

Supplemental documentation provides technical information related to system administration tasks and include the following documents:

•

Oracle Utilities Smart Grid Gateway Server Administration Guide

•

Oracle Utilities Smart Grid Gateway Batch Server Administration Guide

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus (OSB) and Oracle Business Process Execution Language (BPEL) as middleware components. These tools are part of the Oracle SOA Suite. See the Oracle SOA Suite Documentation library (http://www.oracle.com/technetwork/middleware/soasuite/documentation/index.html ) for more information about using these tools.

Embedded Help

Oracle Utilities Smart Grid Gateway, like all Oracle Utilities Application Framework applications, provides extensive internal documentation. For example, detailed descriptions of system objects are included in the objects' maintenance portals. The lifecycle of each business object is described on the Lifecycle tab and depicted in flow diagrams on the Summary tab. This information is extremely useful for implementers and system administrators.

Embedded help is provided for all non-obvious fields in most portals and zones. If a field has associated help text, a ? icon appears next to the field when the zone is displayed.

Online Help

Oracle Utilities Smart Grid Gateway also include context-sensitive help for all the user interface screens users will typically work with as they use the system. Online help contains conceptual information and procedures related to working with the various objects used in the system.

The online help is divided into the following three sections:

•

Oracle Utilities Application Framework: Describes the features and functions of the application framework (F1)

•

Oracle Utilities Service and Measurement Data Foundation: Describes the features and functions provided in the Service and Measurement Data Foundation (D1)

•

Oracle Utilities Smart Grid Gateway Adapters: Describes the features and functions provided in the smart grid gateway adapters (D3, D4, D5, etc.)

Other Documentation

This section describes other documentation provided with Oracle Utilities Smart Grid Gateway.

Installation Documentation

Installation documentation describes the steps involved in the installation and initial set up of the system, and includes the following documents:

•

Oracle Utilities Smart Grid Gateway Quick Install Guide

•

Oracle Utilities Smart Grid Gateway DBA Guide

•

Oracle Utilities Smart Grid Gateway Installation Guide

User Documentation

User documentation provides conceptual information and procedures related to working with the various objects used in the system, and includes the following documents:

•

Oracle Utilities Application Framework Business Process Guide

•

Oracle Utilities Application Framework Administration Guide

•

Oracle Utilities Service and Measurement Data Foundation User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr User’s Guide

•

Oracle Utilities Smart Grid Gateway MV90 Adapter for Itron User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Echelon User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Sensus User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Silver Springs Network User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter Development Kit User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Itron OpenWay User’s Guide

Adapter Configuration Documentation

Adapter configuration documentation provides technical information related to vendor-specific Smart Grid Gateway adapters, and includes the following documents:

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr Configuration Guide

•

Oracle Utilities Smart Grid Gateway MV90 Adapter for Itron Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Echelon Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Sensus Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Silver Springs Network Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter Development Kit Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Itron OpenWay Configuration Guide

Supplemental Documentation

Supplemental documentation provides technical information related to system administration tasks and include the following documents:

•

Oracle Utilities Smart Grid Gateway Server Administration Guide

•

Oracle Utilities Smart Grid Gateway Batch Server Administration Guide

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus (OSB) and Oracle Business Process Execution Language (BPEL) as middleware components. These tools are part of the Oracle SOA Suite. See the Oracle SOA Suite Documentation library (http://www.oracle.com/technetwork/middleware/soasuite/documentation/index.html ) for more information about using these tools.

Embedded Help

Oracle Utilities Smart Grid Gateway, like all Oracle Utilities Application Framework applications, provides extensive internal documentation. For example, detailed descriptions of system objects are included in the objects' maintenance portals. The lifecycle of each business object is described on the Lifecycle tab and depicted in flow diagrams on the Summary tab. This information is extremely useful for implementers and system administrators.

Embedded help is provided for all non-obvious fields in most portals and zones. If a field has associated help text, a ? icon appears next to the field when the zone is displayed.

Online Help

Oracle Utilities Smart Grid Gateway also include context-sensitive help for all the user interface screens users will typically work with as they use the system. Online help contains conceptual information and procedures related to working with the various objects used in the system.

The online help is divided into the following three sections:

•

Oracle Utilities Application Framework: Describes the features and functions of the application framework (F1)

•

Oracle Utilities Service and Measurement Data Foundation: Describes the features and functions provided in the Service and Measurement Data Foundation (D1)

•

Oracle Utilities Smart Grid Gateway Adapters: Describes the features and functions provided in the smart grid gateway adapters (D3, D4, D5, etc.)

Other Documentation

This section describes other documentation provided with Oracle Utilities Smart Grid Gateway.

Installation Documentation

Installation documentation describes the steps involved in the installation and initial set up of the system, and includes the following documents:

•

Oracle Utilities Smart Grid Gateway Quick Install Guide

•

Oracle Utilities Smart Grid Gateway DBA Guide

•

Oracle Utilities Smart Grid Gateway Installation Guide

User Documentation

User documentation provides conceptual information and procedures related to working with the various objects used in the system, and includes the following documents:

•

Oracle Utilities Application Framework Business Process Guide

•

Oracle Utilities Application Framework Administration Guide

•

Oracle Utilities Service and Measurement Data Foundation User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr User’s Guide

•

Oracle Utilities Smart Grid Gateway MV90 Adapter for Itron User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Echelon User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Sensus User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Silver Springs Network User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter Development Kit User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Itron OpenWay User’s Guide

Adapter Configuration Documentation

Adapter configuration documentation provides technical information related to vendor-specific Smart Grid Gateway adapters, and includes the following documents:

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr Configuration Guide

•

Oracle Utilities Smart Grid Gateway MV90 Adapter for Itron Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Echelon Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Sensus Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Silver Springs Network Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter Development Kit Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Itron OpenWay Configuration Guide

Supplemental Documentation

Supplemental documentation provides technical information related to system administration tasks and include the following documents:

•

Oracle Utilities Smart Grid Gateway Server Administration Guide

•

Oracle Utilities Smart Grid Gateway Batch Server Administration Guide

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus (OSB) and Oracle Business Process Execution Language (BPEL) as middleware components. These tools are part of the Oracle SOA Suite. See the Oracle SOA Suite Documentation library (http://www.oracle.com/technetwork/middleware/soasuite/documentation/index.html ) for more information about using these tools.

Embedded Help

Oracle Utilities Smart Grid Gateway, like all Oracle Utilities Application Framework applications, provides extensive internal documentation. For example, detailed descriptions of system objects are included in the objects' maintenance portals. The lifecycle of each business object is described on the Lifecycle tab and depicted in flow diagrams on the Summary tab. This information is extremely useful for implementers and system administrators.

Embedded help is provided for all non-obvious fields in most portals and zones. If a field has associated help text, a ? icon appears next to the field when the zone is displayed.

Online Help

Oracle Utilities Smart Grid Gateway also include context-sensitive help for all the user interface screens users will typically work with as they use the system. Online help contains conceptual information and procedures related to working with the various objects used in the system.

The online help is divided into the following three sections:

•

Oracle Utilities Application Framework: Describes the features and functions of the application framework (F1)

•

Oracle Utilities Service and Measurement Data Foundation: Describes the features and functions provided in the Service and Measurement Data Foundation (D1)

•

Oracle Utilities Smart Grid Gateway Adapters: Describes the features and functions provided in the smart grid gateway adapters (D3, D4, D5, etc.)

Other Documentation

This section describes other documentation provided with Oracle Utilities Smart Grid Gateway.

Installation Documentation

Installation documentation describes the steps involved in the installation and initial set up of the system, and includes the following documents:

•

Oracle Utilities Smart Grid Gateway Quick Install Guide

•

Oracle Utilities Smart Grid Gateway DBA Guide

•

Oracle Utilities Smart Grid Gateway Installation Guide

User Documentation

User documentation provides conceptual information and procedures related to working with the various objects used in the system, and includes the following documents:

•

Oracle Utilities Application Framework Business Process Guide

•

Oracle Utilities Application Framework Administration Guide

•

Oracle Utilities Service and Measurement Data Foundation User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr User’s Guide

•

Oracle Utilities Smart Grid Gateway MV90 Adapter for Itron User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Echelon User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Sensus User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Silver Springs Network User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter Development Kit User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Itron OpenWay User’s Guide

Adapter Configuration Documentation

Adapter configuration documentation provides technical information related to vendor-specific Smart Grid Gateway adapters, and includes the following documents:

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr Configuration Guide

•

Oracle Utilities Smart Grid Gateway MV90 Adapter for Itron Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Echelon Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Sensus Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Silver Springs Network Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter Development Kit Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Itron OpenWay Configuration Guide

Supplemental Documentation

Supplemental documentation provides technical information related to system administration tasks and include the following documents:

•

Oracle Utilities Smart Grid Gateway Server Administration Guide

•

Oracle Utilities Smart Grid Gateway Batch Server Administration Guide

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus (OSB) and Oracle Business Process Execution Language (BPEL) as middleware components. These tools are part of the Oracle SOA Suite. See the Oracle SOA Suite Documentation library (http://www.oracle.com/technetwork/middleware/soasuite/documentation/index.html ) for more information about using these tools.

Embedded Help

Oracle Utilities Smart Grid Gateway, like all Oracle Utilities Application Framework applications, provides extensive internal documentation. For example, detailed descriptions of system objects are included in the objects' maintenance portals. The lifecycle of each business object is described on the Lifecycle tab and depicted in flow diagrams on the Summary tab. This information is extremely useful for implementers and system administrators.

Embedded help is provided for all non-obvious fields in most portals and zones. If a field has associated help text, a ? icon appears next to the field when the zone is displayed.

Online Help

Oracle Utilities Smart Grid Gateway also include context-sensitive help for all the user interface screens users will typically work with as they use the system. Online help contains conceptual information and procedures related to working with the various objects used in the system.

The online help is divided into the following three sections:

•

Oracle Utilities Application Framework: Describes the features and functions of the application framework (F1)

•

Oracle Utilities Service and Measurement Data Foundation: Describes the features and functions provided in the Service and Measurement Data Foundation (D1)

•

Oracle Utilities Smart Grid Gateway Adapters: Describes the features and functions provided in the smart grid gateway adapters (D3, D4, D5, etc.)

Other Documentation

This section describes other documentation provided with Oracle Utilities Smart Grid Gateway.

Installation Documentation

Installation documentation describes the steps involved in the installation and initial set up of the system, and includes the following documents:

•

Oracle Utilities Smart Grid Gateway Quick Install Guide

•

Oracle Utilities Smart Grid Gateway DBA Guide

•

Oracle Utilities Smart Grid Gateway Installation Guide

User Documentation

User documentation provides conceptual information and procedures related to working with the various objects used in the system, and includes the following documents:

•

Oracle Utilities Application Framework Business Process Guide

•

Oracle Utilities Application Framework Administration Guide

•

Oracle Utilities Service and Measurement Data Foundation User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr User’s Guide

•

Oracle Utilities Smart Grid Gateway MV90 Adapter for Itron User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Echelon User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Sensus User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Silver Springs Network User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter Development Kit User’s Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Itron OpenWay User’s Guide

Adapter Configuration Documentation

Adapter configuration documentation provides technical information related to vendor-specific Smart Grid Gateway adapters, and includes the following documents:

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr Configuration Guide

•

Oracle Utilities Smart Grid Gateway MV90 Adapter for Itron Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Echelon Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Sensus Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Silver Springs Network Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter Development Kit Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Itron OpenWay Configuration Guide

Supplemental Documentation

Supplemental documentation provides technical information related to system administration tasks and include the following documents:

•

Oracle Utilities Smart Grid Gateway Server Administration Guide

•

Oracle Utilities Smart Grid Gateway Batch Server Administration Guide

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus (OSB) and Oracle Business Process Execution Language (BPEL) as middleware components. These tools are part of the Oracle SOA Suite. See the Oracle SOA Suite Documentation library (http://www.oracle.com/technetwork/middleware/soasuite/documentation/index.html ) for more information about using these tools.

Embedded Help

Oracle Utilities Smart Grid Gateway, like all Oracle Utilities Application Framework applications, provides extensive internal documentation. For example, detailed descriptions of system objects are included in the objects' maintenance portals. The lifecycle of each business object is described on the Lifecycle tab and depicted in flow diagrams on the Summary tab. This information is extremely useful for implementers and system administrators.

Embedded help is provided for all non-obvious fields in most portals and zones. If a field has associated help text, a ? icon appears next to the field when the zone is displayed.

Online Help

Oracle Utilities Smart Grid Gateway also include context-sensitive help for all the user interface screens users will typically work with as they use the system. Online help contains conceptual information and procedures related to working with the various objects used in the system.

The online help is divided into the following three sections:

•

Oracle Utilities Application Framework: Describes the features and functions of the application framework (F1)

•

Oracle Utilities Service and Measurement Data Foundation: Describes the features and functions provided in the Service and Measurement Data Foundation (D1)

•

Oracle Utilities Smart Grid Gateway Adapters: Describes the features and functions provided in the smart grid gateway adapters (D3, D4, D5, etc.)

Architecture Overview

Oracle Utilities Smart Grid Gateway is used to maintain information about meters and the service points at which they are installed. The application provides means of recording measurements and events associated with meters in the field as well as the ability to issue commands to meters via head-end systems.

Oracle Utilities Smart Grid Gateway comprises the following functional areas:

•

Device Management: the maintenance of physical meters in the field

•

Device Installation: the maintenance of service points and the installation of meters in the field. This includes the means of registering outside systems to provide consumer-specific processing of meter events and activities

•

Device Communication: the maintenance of communications with head-end systems, including import of usage and events, as well as two-way communications used in issuing meter commands.

•

Validation, Editing, and Estimation: the maintenance of measurement data and the engine used to validate and modify that data as it comes in

Oracle Utilities Smart Grid Gateway is built upon the Oracle Utilities Service and Measurement Data Foundation, a framework that provides shared functionality used by Oracle Utilities Meter Data Management, Oracle Utilities Smart Grid Gateway, and other Oracle Utilities products. Oracle Utilities Smart Grid Gateway and the Oracle Utilities Service and Measurement Data Foundation are built atop the Oracle Utilities Application Framework.

Oracle Utilities Application Framework Configuration Tools

The Oracle Utilities Application Framework (OUAF) configuration tools can be used to create and customize system entities, such as business objects, portals, zones, and UI maps. Refer to the Oracle Utilities Application Framework configuration tools documentation for instructions on using these tools.

This configuration guide does not duplicate the concepts and procedures presented in the Oracle Utilities Application Framework configuration tools documentation; rather, it will identify the specific objects used by Oracle Utilities Smart Grid Gateway that can be configured and customized using the configuration tools, as well as application parameters and objects that can be managed within the application components themselves.

This guide assumes that all individuals responsible for system configuration and implementation will be familiar with the Oracle Utilities Application Framework and will have completed training on the Oracle Utilities Application Framework Configuration Tools.

The following sections discuss some specific topics related to the configuration tools.

"Lite" Business Objects

When a business object is read, the Framework dynamically constructs a SQL statement to retrieve the rows and columns associated with the business object's schema. If a process only needs only a small subset of a business object's elements, a "lite" business object that only references these elements can be used.

These "lite" business objects are used by the business processes (typically the construction of info strings) that only need a small subset of elements. Lite business objects are configured to never allow instances. In other words, they are only used to read existing instances of other business objects.

Later chapters in this book list the various "lite" business objects provided with the base package for each of the types of business objects described (devices, measuring components, service points, etc.)

Data Areas

As described in the Oracle Utilities Application Framework documentation, data areas provide a common schema location for re-used schema structures. Data areas exists solely to help eliminate redundant element declaration. For example, if you have multiple schemas that share a common structure, you can set up a stand-alone data area schema for the common elements and then include it in each of the other schemas.

Many of the base package schemas make use of data areas, and Oracle recommends that you take advantage of data areas where possible to avoid redundant data definition.

See Appendix B : Base Package Data Areas for a list of the base package data areas provided with Oracle Utilities Service and Measurement Data Foundation and Oracle Utilities Smart Grid Gateway.

Algorithms

Many functions in the system are performed using user-defined algorithms (also referred to as plug-ins). For example, user-defined algorithms can be used to perform custom validation, editing, and estimation logic, or retrieve characteristic values for factors.

Custom algorithms allow implementers to modify how the system responds to certain system events. The system provides a means where the custom algorithms can be invoked instead of the base package algorithms provided with the system. For instructions on creating custom algorithms and algorithm types, see the Framework documentation. To view information about specific algorithms provided with the base system, use the Application Viewer (also described in the Framework documentation). The Application Viewer provides information about the base logic, inputs, and outputs of each algorithm entity or plug-in spot.

Entity Naming Conventions

Oracle Utilities Smart Grid Gateway system uses naming conventions to identify and distinguish entities that belong to different Oracle applications. These conventions can help you locate entities and understand their context.

Each base product uses a 2-character owner code as a prefix for all its entities. For Oracle Utilities Smart Grid Gateway, these prefixes are as follows:

•

All Oracle Utilities Application Framework entities start with "F1"

•

All Oracle Utilities Service and Measurement Data Foundation entities start with "D1"

•

All Oracle Utilities Smart Grid Gateway adapter entities start with "D3", "D4", "D5", etc.

Oracle recommends that you follow these naming conventions and develop your own set of conventions for the entities you create. If you create new entities, DO NOT use these prefixes; use the prefix "CM" (or some other unique prefix) to identify entities that have been customized.

Configuration Process Overview

This section provides a high-level overview of some of the steps involved in the configuration process when implementing Oracle Utilities Application Framework products such as Oracle Utilities Smart Grid Gateway.

Note : The following sections are a simplification of an involved process, and are provided as guidelines only. Refer to the Oracle Utilities Application Framework documentation for detailed information about business objects and other objects referenced below.

Basic Configuration Steps - Design Your Business Objects

Much of the configuration involved in implementing Oracle Utilities Smart Grid Gateway is centered around the creation of business objects. Nearly every object or set of data used by Oracle Utilities Smart Grid Gateway is defined in business object, including meters and registers (devices and measuring components), service points, contacts, measurement data, validation rules, usage calculation rules, and more.

Given the prominent role that business objects play, one of the most important steps in implementing Oracle Utilities Smart Grid Gateway is identifying the business objects you will need to create to meet the requirements of your implementation. At a high level, this includes the following steps:

1.

Identify the data to be defined by each business object

This step defines the maintenance object to be used with the business object, and the data elements to include in the business object’s schema. Leverage data areas where possible to minimize redundant data definition.

2.

Identify the processing to be performed by each business object

This step determines the specific algorithms/algorithm types, and business services (and related scripts and service programs) that will be perform the processing required by your business objects.

3.

Identify how users will access and work with each business object (if applicable)

This defines the portals, zones, navigation options, BPA scripts, etc. you will need to develop to allow users access to your business objects.

Basic Configuration Steps - Create Your Business Objects

After identifying the above information, the next step is to create the business objects used in your implementation. At a high level, this includes the following steps:

1.

Create configuration objects

Before you can create your business objects, you must first create the various configuration objects used by each business object, including:

•

Application Services

•

UI Maps (display and maintenance)

•

Navigation Options

•

Service Scripts

•

Algorithm Types/Algorithms

•

BPA Scripts/Business Service

•

Other business objects

•

Etc.

Where possible, leverage base package objects instead of creating your own to minimize data redundancy.

2.

Create the business object

Once the configuration objects used by the business object are in place, you can create the actual business object itself using the Business Object portal, referencing the configuration objects created in step 1 as appropriate.

Later chapters in this book provide examples of many of the base package business objects provided with the system. These are provided to illustrate how the base package objects were designed, and to serve as the basis for the business objects you create as part of your implementation.

Basic Configuration Steps - Create Portals and Zones

If the base package portals and zones are not sufficient to meet the requirements of your implementation, you may have to create your own to allow users to work with your business objects. This can include creating the following:

•

Context Menus

•

Menus and Menu Items

•

Navigation Keys

•

Navigation Options

•

Portals

•

Zones

Basic Configuration Steps - Create Master Data

The "master" data used by Oracle Utilities Smart Grid Gateway includes the various entities used in your implementation, such as devices, measuring components, service points, VEE rules, etc. This data must be created in the system before you can process measurement data and create bill determinants from the data. Creating this data includes the following steps:

1.

Create admin "type" data.

Many of the objects used by Oracle Utilities Smart Grid Gateway have corresponding admin "type" objects that are used to define attributes common to instances of that type of object. For example, Device Types are used to define attributes common to devices of a specific type. One of the most important attributes defined by an admin "type" object is the business object that will be used for instances of the object of that type. For example, devices created from a Device Type that references the "D1-SmartMeter" device business object will be based on that business object.

The Admin "Type" Objects table below lists the core objects used by Oracle Utilities Smart Grid Gateway and their corresponding admin "type" objects.

2.

Create instances of the data.

Once the admin "type" data is in place, you can create the instances of the master data objects used in your implementation. These instances are the individual devices, measuring components, service points, VEE rules, usage subscriptions, etc. that will be used in processing measurement data, calculating usage and bill determinants, and so on.

Admin "Type" Objects.

Object

Admin "Type" Object

Activity

Activity Type

Communication

Communication Type

Contact

Contact Type

Device

Device Type

Device Event

Device Event Type

Device Configuration

Device Configuration Type

Measuring Component

Measuring Component Type

Service Point

Service Point Type

Basic Configuration Steps - Create Master Data

The "master" data used by Oracle Utilities Smart Grid Gateway includes the various entities used in your implementation, such as devices, measuring components, service points, VEE rules, etc. This data must be created in the system before you can process measurement data and create bill determinants from the data. Creating this data includes the following steps:

1.

Create admin "type" data.

Many of the objects used by Oracle Utilities Smart Grid Gateway have corresponding admin "type" objects that are used to define attributes common to instances of that type of object. For example, Device Types are used to define attributes common to devices of a specific type. One of the most important attributes defined by an admin "type" object is the business object that will be used for instances of the object of that type. For example, devices created from a Device Type that references the "D1-SmartMeter" device business object will be based on that business object.

The Admin "Type" Objects table below lists the core objects used by Oracle Utilities Smart Grid Gateway and their corresponding admin "type" objects.

2.

Create instances of the data.

Once the admin "type" data is in place, you can create the instances of the master data objects used in your implementation. These instances are the individual devices, measuring components, service points, VEE rules, usage subscriptions, etc. that will be used in processing measurement data, calculating usage and bill determinants, and so on.

Admin "Type" Objects.

Object

Admin "Type" Object

Activity

Activity Type

Communication

Communication Type

Contact

Contact Type

Device

Device Type

Device Event

Device Event Type

Device Configuration

Device Configuration Type

Measuring Component

Measuring Component Type

Service Point

Service Point Type

General Configuration

This chapter describes configuration of general components, including the following:

•

Installation Options

•

Master Configuration

Installation Options

Installation options define the individual applications installed on your system and identify algorithms used to implement core system functions. These options also define global parameters such as the administrative menu style (alphabetical or functional), the country, language, currency code, as well as the base time zone to use for this implementation.

Installation options are stored in the installation record for your system. Use the Installation Options - Framework portal to configure these options. This portal is part of the OUAF and is described in detail in the Framework documentation.

Base Time Zone

The date/time attributes for all time-sensitive application entities, including start and end dates, are stored in the server application time zone in standard time and displayed in that time zone's legal time, which is the standard time adjusted for any seasonal shift.

The server time zone, also referred to as the Base Time Zone, must be correctly specified on the installation options record.

Note : The installation record does not dictate the server time zone, but rather must match it.

Installation Algorithms

Installation algorithms implement global system functions and can be customized for each implementation. The base package supports the following installation options for Meter Data Management-related system events:

•

Geocoding Service : Responsible for geocoding an address (converting an address to a geocode latitude/longitude pair).

•

Global Context : Sets global contexts (displayed in the Global Context dashboard zone) based on the value of existing global contexts. For example, if the Service Point is specified, this algorithm sets the Device by finding the most recently installed Device on the service point. It then sets the Measuring Component by finding the most effective Device Configuration and retrieving any measuring component linked to it. It then sets the Usage Subscription by finding the most recent active usage subscription linked to the service point. The contact is set by finding the main contact for the usage subscription.

Master Configuration

Master Configuration is a source of global parameter records used by a system implementation.

The Oracle Utilities meter data products use a Global Configuration record that controls core system functions. This record must be set up for the system to properly operate. See Admin Setup Reference Tables for more information on when to set up this record.

Service and Measurement Data Foundation Master Configurations

The following master configurations are used by products that leverage the Oracle Utilities Service and Measurement Data Foundation, including Oracle Utilities Meter Data Management.

Generic BI Configuration

This master configuration defines options related to extraction of flat files used with Oracle Utilities Business Intelligence. Note that this master configuration is used by all products based on the Oracle Utilities Application Framework.

Hijri to Gregorian Date Mapping

The Hijri to Gregorian Date Mapping option is used to define the relationship between Hijri dates and Gregorian dates for each year.

Master Data Synchronization Configuration

The Master Data Synchronization Configuration option is used to define all foreign key references that need resolution. Each foreign key reference references the view that contains the external key / production key cross-reference. For entities that undergo both the initial and the ongoing synchronization, two views are specified. For entities that undergo the ongoing synchronization, an external system / ID type mapping is specified to cater for entities that might be synchronizing from more than one external system.

MDM-Specific Business Intelligence Master Configuration

The MDM-Specific Business Intelligence Master Configuration is primarily used to configure the information that will be used in the extraction of data for business intelligence.

ODM Integration Master Configuration

The ODM Integration Master Configuration is used to define options related to integration of Oracle Utilities Operational Device Management to Oracle Utilities Meter Data Management. Specific options defined include the External System that represents the Oracle Utilities Operational Device Management application, its URL, and the number of hours Oracle Utilities Meter Data Management waits for a response from Oracle Utilities Operational Device Management before transitioning an outbound synchronization request to the error state.

In addition, this configuration defines specific Maintenance Objects being synchronized and corresponding Outbound Message Types used to communicate its information to Oracle Utilities Operational Device Management.

Seeder Sync Master Configuration

The Seeder Sync Master Configuration is used to define the maintenance objects (device, device configuration, etc.) that require synchronization. Each maintenance object references the synchronization business object that needs to be instantiated when processing a synchronization request for that maintenance object. For maintenance objects that undergo both initial and the ongoing synchronization, two business objects are specified.

Self Service Master Configuration

The Self Service Master Configuration defines options used when integrating Oracle Utilities Meter Data Management with Oracle Utilities Self Service. Specific options defined include:

•

Processing Scripts : Used to retrieve information about measuring components, service points/device configurations, and usage subscriptions

•

Service Tasks : Used to define self-service tasks available to Oracle Utilities Self Service users.

•

Supported Scalar Usage Groups : Used to define the scalar usage groups supported when retrieving usage from Oracle Utilities Meter Data Management for access by Oracle Utilities Self Service users.

•

Supported Interval Usage Groups : Used to define the scalar usage groups supported when retrieving usage from Oracle Utilities Meter Data Management for access by Oracle Utilities Self Service users.

See the Oracle Utilities Self Service Implementation Guide for more information about configuring Oracle Utilities Meter Data Management for use with Oracle Utilities Self Service.

Service and Measurement Data Foundation Master Configurations

The following master configurations are used by products that leverage the Oracle Utilities Service and Measurement Data Foundation, including Oracle Utilities Meter Data Management.

Generic BI Configuration

This master configuration defines options related to extraction of flat files used with Oracle Utilities Business Intelligence. Note that this master configuration is used by all products based on the Oracle Utilities Application Framework.

Hijri to Gregorian Date Mapping

The Hijri to Gregorian Date Mapping option is used to define the relationship between Hijri dates and Gregorian dates for each year.

Master Data Synchronization Configuration

The Master Data Synchronization Configuration option is used to define all foreign key references that need resolution. Each foreign key reference references the view that contains the external key / production key cross-reference. For entities that undergo both the initial and the ongoing synchronization, two views are specified. For entities that undergo the ongoing synchronization, an external system / ID type mapping is specified to cater for entities that might be synchronizing from more than one external system.

MDM-Specific Business Intelligence Master Configuration

The MDM-Specific Business Intelligence Master Configuration is primarily used to configure the information that will be used in the extraction of data for business intelligence.

ODM Integration Master Configuration

The ODM Integration Master Configuration is used to define options related to integration of Oracle Utilities Operational Device Management to Oracle Utilities Meter Data Management. Specific options defined include the External System that represents the Oracle Utilities Operational Device Management application, its URL, and the number of hours Oracle Utilities Meter Data Management waits for a response from Oracle Utilities Operational Device Management before transitioning an outbound synchronization request to the error state.

In addition, this configuration defines specific Maintenance Objects being synchronized and corresponding Outbound Message Types used to communicate its information to Oracle Utilities Operational Device Management.

Seeder Sync Master Configuration

The Seeder Sync Master Configuration is used to define the maintenance objects (device, device configuration, etc.) that require synchronization. Each maintenance object references the synchronization business object that needs to be instantiated when processing a synchronization request for that maintenance object. For maintenance objects that undergo both initial and the ongoing synchronization, two business objects are specified.

Self Service Master Configuration

The Self Service Master Configuration defines options used when integrating Oracle Utilities Meter Data Management with Oracle Utilities Self Service. Specific options defined include:

•

Processing Scripts : Used to retrieve information about measuring components, service points/device configurations, and usage subscriptions

•

Service Tasks : Used to define self-service tasks available to Oracle Utilities Self Service users.

•

Supported Scalar Usage Groups : Used to define the scalar usage groups supported when retrieving usage from Oracle Utilities Meter Data Management for access by Oracle Utilities Self Service users.

•

Supported Interval Usage Groups : Used to define the scalar usage groups supported when retrieving usage from Oracle Utilities Meter Data Management for access by Oracle Utilities Self Service users.

See the Oracle Utilities Self Service Implementation Guide for more information about configuring Oracle Utilities Meter Data Management for use with Oracle Utilities Self Service.

Service and Measurement Data Foundation Master Configurations

The following master configurations are used by products that leverage the Oracle Utilities Service and Measurement Data Foundation, including Oracle Utilities Meter Data Management.

Generic BI Configuration

This master configuration defines options related to extraction of flat files used with Oracle Utilities Business Intelligence. Note that this master configuration is used by all products based on the Oracle Utilities Application Framework.

Hijri to Gregorian Date Mapping

The Hijri to Gregorian Date Mapping option is used to define the relationship between Hijri dates and Gregorian dates for each year.

Master Data Synchronization Configuration

The Master Data Synchronization Configuration option is used to define all foreign key references that need resolution. Each foreign key reference references the view that contains the external key / production key cross-reference. For entities that undergo both the initial and the ongoing synchronization, two views are specified. For entities that undergo the ongoing synchronization, an external system / ID type mapping is specified to cater for entities that might be synchronizing from more than one external system.

MDM-Specific Business Intelligence Master Configuration

The MDM-Specific Business Intelligence Master Configuration is primarily used to configure the information that will be used in the extraction of data for business intelligence.

ODM Integration Master Configuration

The ODM Integration Master Configuration is used to define options related to integration of Oracle Utilities Operational Device Management to Oracle Utilities Meter Data Management. Specific options defined include the External System that represents the Oracle Utilities Operational Device Management application, its URL, and the number of hours Oracle Utilities Meter Data Management waits for a response from Oracle Utilities Operational Device Management before transitioning an outbound synchronization request to the error state.

In addition, this configuration defines specific Maintenance Objects being synchronized and corresponding Outbound Message Types used to communicate its information to Oracle Utilities Operational Device Management.

Seeder Sync Master Configuration

The Seeder Sync Master Configuration is used to define the maintenance objects (device, device configuration, etc.) that require synchronization. Each maintenance object references the synchronization business object that needs to be instantiated when processing a synchronization request for that maintenance object. For maintenance objects that undergo both initial and the ongoing synchronization, two business objects are specified.

Self Service Master Configuration

The Self Service Master Configuration defines options used when integrating Oracle Utilities Meter Data Management with Oracle Utilities Self Service. Specific options defined include:

•

Processing Scripts : Used to retrieve information about measuring components, service points/device configurations, and usage subscriptions

•

Service Tasks : Used to define self-service tasks available to Oracle Utilities Self Service users.

•

Supported Scalar Usage Groups : Used to define the scalar usage groups supported when retrieving usage from Oracle Utilities Meter Data Management for access by Oracle Utilities Self Service users.

•

Supported Interval Usage Groups : Used to define the scalar usage groups supported when retrieving usage from Oracle Utilities Meter Data Management for access by Oracle Utilities Self Service users.

See the Oracle Utilities Self Service Implementation Guide for more information about configuring Oracle Utilities Meter Data Management for use with Oracle Utilities Self Service.

Service and Measurement Data Foundation Master Configurations

The following master configurations are used by products that leverage the Oracle Utilities Service and Measurement Data Foundation, including Oracle Utilities Meter Data Management.

Generic BI Configuration

This master configuration defines options related to extraction of flat files used with Oracle Utilities Business Intelligence. Note that this master configuration is used by all products based on the Oracle Utilities Application Framework.

Hijri to Gregorian Date Mapping

The Hijri to Gregorian Date Mapping option is used to define the relationship between Hijri dates and Gregorian dates for each year.

Master Data Synchronization Configuration

The Master Data Synchronization Configuration option is used to define all foreign key references that need resolution. Each foreign key reference references the view that contains the external key / production key cross-reference. For entities that undergo both the initial and the ongoing synchronization, two views are specified. For entities that undergo the ongoing synchronization, an external system / ID type mapping is specified to cater for entities that might be synchronizing from more than one external system.

MDM-Specific Business Intelligence Master Configuration

The MDM-Specific Business Intelligence Master Configuration is primarily used to configure the information that will be used in the extraction of data for business intelligence.

ODM Integration Master Configuration

The ODM Integration Master Configuration is used to define options related to integration of Oracle Utilities Operational Device Management to Oracle Utilities Meter Data Management. Specific options defined include the External System that represents the Oracle Utilities Operational Device Management application, its URL, and the number of hours Oracle Utilities Meter Data Management waits for a response from Oracle Utilities Operational Device Management before transitioning an outbound synchronization request to the error state.

In addition, this configuration defines specific Maintenance Objects being synchronized and corresponding Outbound Message Types used to communicate its information to Oracle Utilities Operational Device Management.

Seeder Sync Master Configuration

The Seeder Sync Master Configuration is used to define the maintenance objects (device, device configuration, etc.) that require synchronization. Each maintenance object references the synchronization business object that needs to be instantiated when processing a synchronization request for that maintenance object. For maintenance objects that undergo both initial and the ongoing synchronization, two business objects are specified.

Self Service Master Configuration

The Self Service Master Configuration defines options used when integrating Oracle Utilities Meter Data Management with Oracle Utilities Self Service. Specific options defined include:

•

Processing Scripts : Used to retrieve information about measuring components, service points/device configurations, and usage subscriptions

•

Service Tasks : Used to define self-service tasks available to Oracle Utilities Self Service users.

•

Supported Scalar Usage Groups : Used to define the scalar usage groups supported when retrieving usage from Oracle Utilities Meter Data Management for access by Oracle Utilities Self Service users.

•

Supported Interval Usage Groups : Used to define the scalar usage groups supported when retrieving usage from Oracle Utilities Meter Data Management for access by Oracle Utilities Self Service users.

See the Oracle Utilities Self Service Implementation Guide for more information about configuring Oracle Utilities Meter Data Management for use with Oracle Utilities Self Service.

Service and Measurement Data Foundation Master Configurations

The following master configurations are used by products that leverage the Oracle Utilities Service and Measurement Data Foundation, including Oracle Utilities Meter Data Management.

Generic BI Configuration

This master configuration defines options related to extraction of flat files used with Oracle Utilities Business Intelligence. Note that this master configuration is used by all products based on the Oracle Utilities Application Framework.

Hijri to Gregorian Date Mapping

The Hijri to Gregorian Date Mapping option is used to define the relationship between Hijri dates and Gregorian dates for each year.

Master Data Synchronization Configuration

The Master Data Synchronization Configuration option is used to define all foreign key references that need resolution. Each foreign key reference references the view that contains the external key / production key cross-reference. For entities that undergo both the initial and the ongoing synchronization, two views are specified. For entities that undergo the ongoing synchronization, an external system / ID type mapping is specified to cater for entities that might be synchronizing from more than one external system.

MDM-Specific Business Intelligence Master Configuration

The MDM-Specific Business Intelligence Master Configuration is primarily used to configure the information that will be used in the extraction of data for business intelligence.

ODM Integration Master Configuration

The ODM Integration Master Configuration is used to define options related to integration of Oracle Utilities Operational Device Management to Oracle Utilities Meter Data Management. Specific options defined include the External System that represents the Oracle Utilities Operational Device Management application, its URL, and the number of hours Oracle Utilities Meter Data Management waits for a response from Oracle Utilities Operational Device Management before transitioning an outbound synchronization request to the error state.

In addition, this configuration defines specific Maintenance Objects being synchronized and corresponding Outbound Message Types used to communicate its information to Oracle Utilities Operational Device Management.

Seeder Sync Master Configuration

The Seeder Sync Master Configuration is used to define the maintenance objects (device, device configuration, etc.) that require synchronization. Each maintenance object references the synchronization business object that needs to be instantiated when processing a synchronization request for that maintenance object. For maintenance objects that undergo both initial and the ongoing synchronization, two business objects are specified.

Self Service Master Configuration

The Self Service Master Configuration defines options used when integrating Oracle Utilities Meter Data Management with Oracle Utilities Self Service. Specific options defined include:

•

Processing Scripts : Used to retrieve information about measuring components, service points/device configurations, and usage subscriptions

•

Service Tasks : Used to define self-service tasks available to Oracle Utilities Self Service users.

•

Supported Scalar Usage Groups : Used to define the scalar usage groups supported when retrieving usage from Oracle Utilities Meter Data Management for access by Oracle Utilities Self Service users.

•

Supported Interval Usage Groups : Used to define the scalar usage groups supported when retrieving usage from Oracle Utilities Meter Data Management for access by Oracle Utilities Self Service users.

See the Oracle Utilities Self Service Implementation Guide for more information about configuring Oracle Utilities Meter Data Management for use with Oracle Utilities Self Service.

Service and Measurement Data Foundation Master Configurations

The following master configurations are used by products that leverage the Oracle Utilities Service and Measurement Data Foundation, including Oracle Utilities Meter Data Management.

Generic BI Configuration

This master configuration defines options related to extraction of flat files used with Oracle Utilities Business Intelligence. Note that this master configuration is used by all products based on the Oracle Utilities Application Framework.

Hijri to Gregorian Date Mapping

The Hijri to Gregorian Date Mapping option is used to define the relationship between Hijri dates and Gregorian dates for each year.

Master Data Synchronization Configuration

The Master Data Synchronization Configuration option is used to define all foreign key references that need resolution. Each foreign key reference references the view that contains the external key / production key cross-reference. For entities that undergo both the initial and the ongoing synchronization, two views are specified. For entities that undergo the ongoing synchronization, an external system / ID type mapping is specified to cater for entities that might be synchronizing from more than one external system.

MDM-Specific Business Intelligence Master Configuration

The MDM-Specific Business Intelligence Master Configuration is primarily used to configure the information that will be used in the extraction of data for business intelligence.

ODM Integration Master Configuration

The ODM Integration Master Configuration is used to define options related to integration of Oracle Utilities Operational Device Management to Oracle Utilities Meter Data Management. Specific options defined include the External System that represents the Oracle Utilities Operational Device Management application, its URL, and the number of hours Oracle Utilities Meter Data Management waits for a response from Oracle Utilities Operational Device Management before transitioning an outbound synchronization request to the error state.

In addition, this configuration defines specific Maintenance Objects being synchronized and corresponding Outbound Message Types used to communicate its information to Oracle Utilities Operational Device Management.

Seeder Sync Master Configuration

The Seeder Sync Master Configuration is used to define the maintenance objects (device, device configuration, etc.) that require synchronization. Each maintenance object references the synchronization business object that needs to be instantiated when processing a synchronization request for that maintenance object. For maintenance objects that undergo both initial and the ongoing synchronization, two business objects are specified.

Self Service Master Configuration

The Self Service Master Configuration defines options used when integrating Oracle Utilities Meter Data Management with Oracle Utilities Self Service. Specific options defined include:

•

Processing Scripts : Used to retrieve information about measuring components, service points/device configurations, and usage subscriptions

•

Service Tasks : Used to define self-service tasks available to Oracle Utilities Self Service users.

•

Supported Scalar Usage Groups : Used to define the scalar usage groups supported when retrieving usage from Oracle Utilities Meter Data Management for access by Oracle Utilities Self Service users.

•

Supported Interval Usage Groups : Used to define the scalar usage groups supported when retrieving usage from Oracle Utilities Meter Data Management for access by Oracle Utilities Self Service users.

See the Oracle Utilities Self Service Implementation Guide for more information about configuring Oracle Utilities Meter Data Management for use with Oracle Utilities Self Service.

Service and Measurement Data Foundation Master Configurations

The following master configurations are used by products that leverage the Oracle Utilities Service and Measurement Data Foundation, including Oracle Utilities Meter Data Management.

Generic BI Configuration

This master configuration defines options related to extraction of flat files used with Oracle Utilities Business Intelligence. Note that this master configuration is used by all products based on the Oracle Utilities Application Framework.

Hijri to Gregorian Date Mapping

The Hijri to Gregorian Date Mapping option is used to define the relationship between Hijri dates and Gregorian dates for each year.

Master Data Synchronization Configuration

The Master Data Synchronization Configuration option is used to define all foreign key references that need resolution. Each foreign key reference references the view that contains the external key / production key cross-reference. For entities that undergo both the initial and the ongoing synchronization, two views are specified. For entities that undergo the ongoing synchronization, an external system / ID type mapping is specified to cater for entities that might be synchronizing from more than one external system.

MDM-Specific Business Intelligence Master Configuration

The MDM-Specific Business Intelligence Master Configuration is primarily used to configure the information that will be used in the extraction of data for business intelligence.

ODM Integration Master Configuration

The ODM Integration Master Configuration is used to define options related to integration of Oracle Utilities Operational Device Management to Oracle Utilities Meter Data Management. Specific options defined include the External System that represents the Oracle Utilities Operational Device Management application, its URL, and the number of hours Oracle Utilities Meter Data Management waits for a response from Oracle Utilities Operational Device Management before transitioning an outbound synchronization request to the error state.

In addition, this configuration defines specific Maintenance Objects being synchronized and corresponding Outbound Message Types used to communicate its information to Oracle Utilities Operational Device Management.

Seeder Sync Master Configuration

The Seeder Sync Master Configuration is used to define the maintenance objects (device, device configuration, etc.) that require synchronization. Each maintenance object references the synchronization business object that needs to be instantiated when processing a synchronization request for that maintenance object. For maintenance objects that undergo both initial and the ongoing synchronization, two business objects are specified.

Self Service Master Configuration

The Self Service Master Configuration defines options used when integrating Oracle Utilities Meter Data Management with Oracle Utilities Self Service. Specific options defined include:

•

Processing Scripts : Used to retrieve information about measuring components, service points/device configurations, and usage subscriptions

•

Service Tasks : Used to define self-service tasks available to Oracle Utilities Self Service users.

•

Supported Scalar Usage Groups : Used to define the scalar usage groups supported when retrieving usage from Oracle Utilities Meter Data Management for access by Oracle Utilities Self Service users.

•

Supported Interval Usage Groups : Used to define the scalar usage groups supported when retrieving usage from Oracle Utilities Meter Data Management for access by Oracle Utilities Self Service users.

See the Oracle Utilities Self Service Implementation Guide for more information about configuring Oracle Utilities Meter Data Management for use with Oracle Utilities Self Service.

Service and Measurement Data Foundation Master Configurations

The following master configurations are used by products that leverage the Oracle Utilities Service and Measurement Data Foundation, including Oracle Utilities Meter Data Management.

Generic BI Configuration

This master configuration defines options related to extraction of flat files used with Oracle Utilities Business Intelligence. Note that this master configuration is used by all products based on the Oracle Utilities Application Framework.

Hijri to Gregorian Date Mapping

The Hijri to Gregorian Date Mapping option is used to define the relationship between Hijri dates and Gregorian dates for each year.

Master Data Synchronization Configuration

The Master Data Synchronization Configuration option is used to define all foreign key references that need resolution. Each foreign key reference references the view that contains the external key / production key cross-reference. For entities that undergo both the initial and the ongoing synchronization, two views are specified. For entities that undergo the ongoing synchronization, an external system / ID type mapping is specified to cater for entities that might be synchronizing from more than one external system.

MDM-Specific Business Intelligence Master Configuration

The MDM-Specific Business Intelligence Master Configuration is primarily used to configure the information that will be used in the extraction of data for business intelligence.

ODM Integration Master Configuration

The ODM Integration Master Configuration is used to define options related to integration of Oracle Utilities Operational Device Management to Oracle Utilities Meter Data Management. Specific options defined include the External System that represents the Oracle Utilities Operational Device Management application, its URL, and the number of hours Oracle Utilities Meter Data Management waits for a response from Oracle Utilities Operational Device Management before transitioning an outbound synchronization request to the error state.

In addition, this configuration defines specific Maintenance Objects being synchronized and corresponding Outbound Message Types used to communicate its information to Oracle Utilities Operational Device Management.

Seeder Sync Master Configuration

The Seeder Sync Master Configuration is used to define the maintenance objects (device, device configuration, etc.) that require synchronization. Each maintenance object references the synchronization business object that needs to be instantiated when processing a synchronization request for that maintenance object. For maintenance objects that undergo both initial and the ongoing synchronization, two business objects are specified.

Self Service Master Configuration

The Self Service Master Configuration defines options used when integrating Oracle Utilities Meter Data Management with Oracle Utilities Self Service. Specific options defined include:

•

Processing Scripts : Used to retrieve information about measuring components, service points/device configurations, and usage subscriptions

•

Service Tasks : Used to define self-service tasks available to Oracle Utilities Self Service users.

•

Supported Scalar Usage Groups : Used to define the scalar usage groups supported when retrieving usage from Oracle Utilities Meter Data Management for access by Oracle Utilities Self Service users.

•

Supported Interval Usage Groups : Used to define the scalar usage groups supported when retrieving usage from Oracle Utilities Meter Data Management for access by Oracle Utilities Self Service users.

See the Oracle Utilities Self Service Implementation Guide for more information about configuring Oracle Utilities Meter Data Management for use with Oracle Utilities Self Service.

Setting Up Admin Data

This chapter describes the different types of admin data that must be set up and defined as part of implementing and configuring Oracle Utilities Smart Grid Gateway, including:

•

Understanding Admin Data

•

Admin Setup Reference Tables

Understanding Admin Data

This section describes the admin data used by the Oracle Utilities Service and Measurement Data Foundation and related products, including Oracle Utilities Meter Data Management and Oracle Utilities Smart Grid Gateway.

General Admin Data

General admin data are types of data used by multiple functional areas.

Exception Types

Exception types define the properties common to many exceptions.

When creating validation, editing, and estimation (VEE) rules, you might create an exception type for each VEE rule. You might also create more general exception types, such as "Insufficient Data" to be used to signify that a measurement didn't have sufficient data for the VEE rule to execute.

Factors

Factor are a centrally stored set of values for use in validation rules, bill determinants calculations, and other processes.

A factor can have different values depending upon some definable attribute of a system object, such as customer size associated with a service point. Examples of factors can include minimum/maximum thresholds, loss factors, etc. Classes of factors are defined that can have numeric values (as in the above examples), or values pointing to profile measuring components, or VEE groups.

A factor's values are effective-dated values - either a number, a profile measuring component, a VEE group, or some custom-defined value - assigned to a factor and associated to the value of some attribute of a system object. For example, consider a service point that can be classified as residential, commercial, or industrial. The tolerance percentage by which a customer's consumption can exceed last month's consumption can be based on the service point category. For this example, factor values for a single factor called "tolerance percentage" could be: Residential - 20% Commercial - 10% Industrial - 5%.

Service Providers

Service providers are external entities that serve various roles relative to the application.

Service providers can include head-end systems, billing systems to which the application sends bill determinant data, market participants in a deregulated environment, outage management systems that receive meter event data from the application, or other parties that require or provide information to the system.

Service Quantity Identifiers

Service Quantity Identifiers (SQI) are used to further distinguish between measured quantities that have identical UOM/TOU combinations, including situations in which the distinguishing identifier of a UOM is not accurately described as a TOU.

SQIs can also be used as a stand-alone representation of a service quantity that is not measured (one that is not properly described as a UOM) within a usage service quantity collection (such as a billing determinant).

Service Types

Service Types define specific types of service for which usage can be recorded and captured, such as electric, gas, steam, etc.

Time of Use

Time of Use (TOU) periods are modifiers for a given unit of measure that indicate a period of time during which a quantity has been used, such as On-Peak (meaning during a time when the greatest quantity of some consumable is being used), Off-Peak (meaning during a time when the least amount of some consumable is being used), etc.

Units of Measure

Units of Measure (UOM) identify quantities measured and recorded, such as KWH, KW, cubic feet, degrees Celsius, etc. UOMs are based on a specific service type.

Attributes used to define units of measure include the following:

•

Service Type : The type of service (electric, gas, etc.) measured by the UOM

•

Decimal Positions : The number of decimal places used when sending usage transaction service quantities for this UOM to Oracle Utilities Customer Care and Billing by way of the base package Usage Transaction Outbound Message

•

Allowed on Measuring Component : A flag that indicates if the UOM is allowed on Measuring Components

•

Measures Peak Quantity : A flag that indicates if the UOM is used to measure peak quantities or not. An example of a UOM that measures peak quantities is kilowatts (KW).

•

Magnitude : A number that indicates the relative size of the UOM as compared to a single unit of the UOM specified under "Base Unit of Measure." For example, megawatt hours (MWH) have a magnitude of 1,000 as compared to a single kilowatt hour (KWH).

•

Base Unit of Measure : The UOM upon which the current UOM is based. Used in conjunction with magnitude. For example, the base unit of measure for megawatt hours (MWH) with a magnitude of 1,000 would be kilowatt hours (KWH).

General Admin Data

General admin data are types of data used by multiple functional areas.

Exception Types

Exception types define the properties common to many exceptions.

When creating validation, editing, and estimation (VEE) rules, you might create an exception type for each VEE rule. You might also create more general exception types, such as "Insufficient Data" to be used to signify that a measurement didn't have sufficient data for the VEE rule to execute.

Factors

Factor are a centrally stored set of values for use in validation rules, bill determinants calculations, and other processes.

A factor can have different values depending upon some definable attribute of a system object, such as customer size associated with a service point. Examples of factors can include minimum/maximum thresholds, loss factors, etc. Classes of factors are defined that can have numeric values (as in the above examples), or values pointing to profile measuring components, or VEE groups.

A factor's values are effective-dated values - either a number, a profile measuring component, a VEE group, or some custom-defined value - assigned to a factor and associated to the value of some attribute of a system object. For example, consider a service point that can be classified as residential, commercial, or industrial. The tolerance percentage by which a customer's consumption can exceed last month's consumption can be based on the service point category. For this example, factor values for a single factor called "tolerance percentage" could be: Residential - 20% Commercial - 10% Industrial - 5%.

Service Providers

Service providers are external entities that serve various roles relative to the application.

Service providers can include head-end systems, billing systems to which the application sends bill determinant data, market participants in a deregulated environment, outage management systems that receive meter event data from the application, or other parties that require or provide information to the system.

Service Quantity Identifiers

Service Quantity Identifiers (SQI) are used to further distinguish between measured quantities that have identical UOM/TOU combinations, including situations in which the distinguishing identifier of a UOM is not accurately described as a TOU.

SQIs can also be used as a stand-alone representation of a service quantity that is not measured (one that is not properly described as a UOM) within a usage service quantity collection (such as a billing determinant).

Service Types

Service Types define specific types of service for which usage can be recorded and captured, such as electric, gas, steam, etc.

Time of Use

Time of Use (TOU) periods are modifiers for a given unit of measure that indicate a period of time during which a quantity has been used, such as On-Peak (meaning during a time when the greatest quantity of some consumable is being used), Off-Peak (meaning during a time when the least amount of some consumable is being used), etc.

Units of Measure

Units of Measure (UOM) identify quantities measured and recorded, such as KWH, KW, cubic feet, degrees Celsius, etc. UOMs are based on a specific service type.

Attributes used to define units of measure include the following:

•

Service Type : The type of service (electric, gas, etc.) measured by the UOM

•

Decimal Positions : The number of decimal places used when sending usage transaction service quantities for this UOM to Oracle Utilities Customer Care and Billing by way of the base package Usage Transaction Outbound Message

•

Allowed on Measuring Component : A flag that indicates if the UOM is allowed on Measuring Components

•

Measures Peak Quantity : A flag that indicates if the UOM is used to measure peak quantities or not. An example of a UOM that measures peak quantities is kilowatts (KW).

•

Magnitude : A number that indicates the relative size of the UOM as compared to a single unit of the UOM specified under "Base Unit of Measure." For example, megawatt hours (MWH) have a magnitude of 1,000 as compared to a single kilowatt hour (KWH).

•

Base Unit of Measure : The UOM upon which the current UOM is based. Used in conjunction with magnitude. For example, the base unit of measure for megawatt hours (MWH) with a magnitude of 1,000 would be kilowatt hours (KWH).

General Admin Data

General admin data are types of data used by multiple functional areas.

Exception Types

Exception types define the properties common to many exceptions.

When creating validation, editing, and estimation (VEE) rules, you might create an exception type for each VEE rule. You might also create more general exception types, such as "Insufficient Data" to be used to signify that a measurement didn't have sufficient data for the VEE rule to execute.

Factors

Factor are a centrally stored set of values for use in validation rules, bill determinants calculations, and other processes.

A factor can have different values depending upon some definable attribute of a system object, such as customer size associated with a service point. Examples of factors can include minimum/maximum thresholds, loss factors, etc. Classes of factors are defined that can have numeric values (as in the above examples), or values pointing to profile measuring components, or VEE groups.

A factor's values are effective-dated values - either a number, a profile measuring component, a VEE group, or some custom-defined value - assigned to a factor and associated to the value of some attribute of a system object. For example, consider a service point that can be classified as residential, commercial, or industrial. The tolerance percentage by which a customer's consumption can exceed last month's consumption can be based on the service point category. For this example, factor values for a single factor called "tolerance percentage" could be: Residential - 20% Commercial - 10% Industrial - 5%.

Service Providers

Service providers are external entities that serve various roles relative to the application.

Service providers can include head-end systems, billing systems to which the application sends bill determinant data, market participants in a deregulated environment, outage management systems that receive meter event data from the application, or other parties that require or provide information to the system.

Service Quantity Identifiers

Service Quantity Identifiers (SQI) are used to further distinguish between measured quantities that have identical UOM/TOU combinations, including situations in which the distinguishing identifier of a UOM is not accurately described as a TOU.

SQIs can also be used as a stand-alone representation of a service quantity that is not measured (one that is not properly described as a UOM) within a usage service quantity collection (such as a billing determinant).

Service Types

Service Types define specific types of service for which usage can be recorded and captured, such as electric, gas, steam, etc.

Time of Use

Time of Use (TOU) periods are modifiers for a given unit of measure that indicate a period of time during which a quantity has been used, such as On-Peak (meaning during a time when the greatest quantity of some consumable is being used), Off-Peak (meaning during a time when the least amount of some consumable is being used), etc.

Units of Measure

Units of Measure (UOM) identify quantities measured and recorded, such as KWH, KW, cubic feet, degrees Celsius, etc. UOMs are based on a specific service type.

Attributes used to define units of measure include the following:

•

Service Type : The type of service (electric, gas, etc.) measured by the UOM

•

Decimal Positions : The number of decimal places used when sending usage transaction service quantities for this UOM to Oracle Utilities Customer Care and Billing by way of the base package Usage Transaction Outbound Message

•

Allowed on Measuring Component : A flag that indicates if the UOM is allowed on Measuring Components

•

Measures Peak Quantity : A flag that indicates if the UOM is used to measure peak quantities or not. An example of a UOM that measures peak quantities is kilowatts (KW).

•

Magnitude : A number that indicates the relative size of the UOM as compared to a single unit of the UOM specified under "Base Unit of Measure." For example, megawatt hours (MWH) have a magnitude of 1,000 as compared to a single kilowatt hour (KWH).

•

Base Unit of Measure : The UOM upon which the current UOM is based. Used in conjunction with magnitude. For example, the base unit of measure for megawatt hours (MWH) with a magnitude of 1,000 would be kilowatt hours (KWH).

General Admin Data

General admin data are types of data used by multiple functional areas.

Exception Types

Exception types define the properties common to many exceptions.

When creating validation, editing, and estimation (VEE) rules, you might create an exception type for each VEE rule. You might also create more general exception types, such as "Insufficient Data" to be used to signify that a measurement didn't have sufficient data for the VEE rule to execute.

Factors

Factor are a centrally stored set of values for use in validation rules, bill determinants calculations, and other processes.

A factor can have different values depending upon some definable attribute of a system object, such as customer size associated with a service point. Examples of factors can include minimum/maximum thresholds, loss factors, etc. Classes of factors are defined that can have numeric values (as in the above examples), or values pointing to profile measuring components, or VEE groups.

A factor's values are effective-dated values - either a number, a profile measuring component, a VEE group, or some custom-defined value - assigned to a factor and associated to the value of some attribute of a system object. For example, consider a service point that can be classified as residential, commercial, or industrial. The tolerance percentage by which a customer's consumption can exceed last month's consumption can be based on the service point category. For this example, factor values for a single factor called "tolerance percentage" could be: Residential - 20% Commercial - 10% Industrial - 5%.

Service Providers

Service providers are external entities that serve various roles relative to the application.

Service providers can include head-end systems, billing systems to which the application sends bill determinant data, market participants in a deregulated environment, outage management systems that receive meter event data from the application, or other parties that require or provide information to the system.

Service Quantity Identifiers

Service Quantity Identifiers (SQI) are used to further distinguish between measured quantities that have identical UOM/TOU combinations, including situations in which the distinguishing identifier of a UOM is not accurately described as a TOU.

SQIs can also be used as a stand-alone representation of a service quantity that is not measured (one that is not properly described as a UOM) within a usage service quantity collection (such as a billing determinant).

Service Types

Service Types define specific types of service for which usage can be recorded and captured, such as electric, gas, steam, etc.

Time of Use

Time of Use (TOU) periods are modifiers for a given unit of measure that indicate a period of time during which a quantity has been used, such as On-Peak (meaning during a time when the greatest quantity of some consumable is being used), Off-Peak (meaning during a time when the least amount of some consumable is being used), etc.

Units of Measure

Units of Measure (UOM) identify quantities measured and recorded, such as KWH, KW, cubic feet, degrees Celsius, etc. UOMs are based on a specific service type.

Attributes used to define units of measure include the following:

•

Service Type : The type of service (electric, gas, etc.) measured by the UOM

•

Decimal Positions : The number of decimal places used when sending usage transaction service quantities for this UOM to Oracle Utilities Customer Care and Billing by way of the base package Usage Transaction Outbound Message

•

Allowed on Measuring Component : A flag that indicates if the UOM is allowed on Measuring Components

•

Measures Peak Quantity : A flag that indicates if the UOM is used to measure peak quantities or not. An example of a UOM that measures peak quantities is kilowatts (KW).

•

Magnitude : A number that indicates the relative size of the UOM as compared to a single unit of the UOM specified under "Base Unit of Measure." For example, megawatt hours (MWH) have a magnitude of 1,000 as compared to a single kilowatt hour (KWH).

•

Base Unit of Measure : The UOM upon which the current UOM is based. Used in conjunction with magnitude. For example, the base unit of measure for megawatt hours (MWH) with a magnitude of 1,000 would be kilowatt hours (KWH).

General Admin Data

General admin data are types of data used by multiple functional areas.

Exception Types

Exception types define the properties common to many exceptions.

When creating validation, editing, and estimation (VEE) rules, you might create an exception type for each VEE rule. You might also create more general exception types, such as "Insufficient Data" to be used to signify that a measurement didn't have sufficient data for the VEE rule to execute.

Factors

Factor are a centrally stored set of values for use in validation rules, bill determinants calculations, and other processes.

A factor can have different values depending upon some definable attribute of a system object, such as customer size associated with a service point. Examples of factors can include minimum/maximum thresholds, loss factors, etc. Classes of factors are defined that can have numeric values (as in the above examples), or values pointing to profile measuring components, or VEE groups.

A factor's values are effective-dated values - either a number, a profile measuring component, a VEE group, or some custom-defined value - assigned to a factor and associated to the value of some attribute of a system object. For example, consider a service point that can be classified as residential, commercial, or industrial. The tolerance percentage by which a customer's consumption can exceed last month's consumption can be based on the service point category. For this example, factor values for a single factor called "tolerance percentage" could be: Residential - 20% Commercial - 10% Industrial - 5%.

Service Providers

Service providers are external entities that serve various roles relative to the application.

Service providers can include head-end systems, billing systems to which the application sends bill determinant data, market participants in a deregulated environment, outage management systems that receive meter event data from the application, or other parties that require or provide information to the system.

Service Quantity Identifiers

Service Quantity Identifiers (SQI) are used to further distinguish between measured quantities that have identical UOM/TOU combinations, including situations in which the distinguishing identifier of a UOM is not accurately described as a TOU.

SQIs can also be used as a stand-alone representation of a service quantity that is not measured (one that is not properly described as a UOM) within a usage service quantity collection (such as a billing determinant).

Service Types

Service Types define specific types of service for which usage can be recorded and captured, such as electric, gas, steam, etc.

Time of Use

Time of Use (TOU) periods are modifiers for a given unit of measure that indicate a period of time during which a quantity has been used, such as On-Peak (meaning during a time when the greatest quantity of some consumable is being used), Off-Peak (meaning during a time when the least amount of some consumable is being used), etc.

Units of Measure

Units of Measure (UOM) identify quantities measured and recorded, such as KWH, KW, cubic feet, degrees Celsius, etc. UOMs are based on a specific service type.

Attributes used to define units of measure include the following:

•

Service Type : The type of service (electric, gas, etc.) measured by the UOM

•

Decimal Positions : The number of decimal places used when sending usage transaction service quantities for this UOM to Oracle Utilities Customer Care and Billing by way of the base package Usage Transaction Outbound Message

•

Allowed on Measuring Component : A flag that indicates if the UOM is allowed on Measuring Components

•

Measures Peak Quantity : A flag that indicates if the UOM is used to measure peak quantities or not. An example of a UOM that measures peak quantities is kilowatts (KW).

•

Magnitude : A number that indicates the relative size of the UOM as compared to a single unit of the UOM specified under "Base Unit of Measure." For example, megawatt hours (MWH) have a magnitude of 1,000 as compared to a single kilowatt hour (KWH).

•

Base Unit of Measure : The UOM upon which the current UOM is based. Used in conjunction with magnitude. For example, the base unit of measure for megawatt hours (MWH) with a magnitude of 1,000 would be kilowatt hours (KWH).

General Admin Data

General admin data are types of data used by multiple functional areas.

Exception Types

Exception types define the properties common to many exceptions.

When creating validation, editing, and estimation (VEE) rules, you might create an exception type for each VEE rule. You might also create more general exception types, such as "Insufficient Data" to be used to signify that a measurement didn't have sufficient data for the VEE rule to execute.

Factors

Factor are a centrally stored set of values for use in validation rules, bill determinants calculations, and other processes.

A factor can have different values depending upon some definable attribute of a system object, such as customer size associated with a service point. Examples of factors can include minimum/maximum thresholds, loss factors, etc. Classes of factors are defined that can have numeric values (as in the above examples), or values pointing to profile measuring components, or VEE groups.

A factor's values are effective-dated values - either a number, a profile measuring component, a VEE group, or some custom-defined value - assigned to a factor and associated to the value of some attribute of a system object. For example, consider a service point that can be classified as residential, commercial, or industrial. The tolerance percentage by which a customer's consumption can exceed last month's consumption can be based on the service point category. For this example, factor values for a single factor called "tolerance percentage" could be: Residential - 20% Commercial - 10% Industrial - 5%.

Service Providers

Service providers are external entities that serve various roles relative to the application.

Service providers can include head-end systems, billing systems to which the application sends bill determinant data, market participants in a deregulated environment, outage management systems that receive meter event data from the application, or other parties that require or provide information to the system.

Service Quantity Identifiers

Service Quantity Identifiers (SQI) are used to further distinguish between measured quantities that have identical UOM/TOU combinations, including situations in which the distinguishing identifier of a UOM is not accurately described as a TOU.

SQIs can also be used as a stand-alone representation of a service quantity that is not measured (one that is not properly described as a UOM) within a usage service quantity collection (such as a billing determinant).

Service Types

Service Types define specific types of service for which usage can be recorded and captured, such as electric, gas, steam, etc.

Time of Use

Time of Use (TOU) periods are modifiers for a given unit of measure that indicate a period of time during which a quantity has been used, such as On-Peak (meaning during a time when the greatest quantity of some consumable is being used), Off-Peak (meaning during a time when the least amount of some consumable is being used), etc.

Units of Measure

Units of Measure (UOM) identify quantities measured and recorded, such as KWH, KW, cubic feet, degrees Celsius, etc. UOMs are based on a specific service type.

Attributes used to define units of measure include the following:

•

Service Type : The type of service (electric, gas, etc.) measured by the UOM

•

Decimal Positions : The number of decimal places used when sending usage transaction service quantities for this UOM to Oracle Utilities Customer Care and Billing by way of the base package Usage Transaction Outbound Message

•

Allowed on Measuring Component : A flag that indicates if the UOM is allowed on Measuring Components

•

Measures Peak Quantity : A flag that indicates if the UOM is used to measure peak quantities or not. An example of a UOM that measures peak quantities is kilowatts (KW).

•

Magnitude : A number that indicates the relative size of the UOM as compared to a single unit of the UOM specified under "Base Unit of Measure." For example, megawatt hours (MWH) have a magnitude of 1,000 as compared to a single kilowatt hour (KWH).

•

Base Unit of Measure : The UOM upon which the current UOM is based. Used in conjunction with magnitude. For example, the base unit of measure for megawatt hours (MWH) with a magnitude of 1,000 would be kilowatt hours (KWH).

General Admin Data

General admin data are types of data used by multiple functional areas.

Exception Types

Exception types define the properties common to many exceptions.

When creating validation, editing, and estimation (VEE) rules, you might create an exception type for each VEE rule. You might also create more general exception types, such as "Insufficient Data" to be used to signify that a measurement didn't have sufficient data for the VEE rule to execute.

Factors

Factor are a centrally stored set of values for use in validation rules, bill determinants calculations, and other processes.

A factor can have different values depending upon some definable attribute of a system object, such as customer size associated with a service point. Examples of factors can include minimum/maximum thresholds, loss factors, etc. Classes of factors are defined that can have numeric values (as in the above examples), or values pointing to profile measuring components, or VEE groups.

A factor's values are effective-dated values - either a number, a profile measuring component, a VEE group, or some custom-defined value - assigned to a factor and associated to the value of some attribute of a system object. For example, consider a service point that can be classified as residential, commercial, or industrial. The tolerance percentage by which a customer's consumption can exceed last month's consumption can be based on the service point category. For this example, factor values for a single factor called "tolerance percentage" could be: Residential - 20% Commercial - 10% Industrial - 5%.

Service Providers

Service providers are external entities that serve various roles relative to the application.

Service providers can include head-end systems, billing systems to which the application sends bill determinant data, market participants in a deregulated environment, outage management systems that receive meter event data from the application, or other parties that require or provide information to the system.

Service Quantity Identifiers

Service Quantity Identifiers (SQI) are used to further distinguish between measured quantities that have identical UOM/TOU combinations, including situations in which the distinguishing identifier of a UOM is not accurately described as a TOU.

SQIs can also be used as a stand-alone representation of a service quantity that is not measured (one that is not properly described as a UOM) within a usage service quantity collection (such as a billing determinant).

Service Types

Service Types define specific types of service for which usage can be recorded and captured, such as electric, gas, steam, etc.

Time of Use

Time of Use (TOU) periods are modifiers for a given unit of measure that indicate a period of time during which a quantity has been used, such as On-Peak (meaning during a time when the greatest quantity of some consumable is being used), Off-Peak (meaning during a time when the least amount of some consumable is being used), etc.

Units of Measure

Units of Measure (UOM) identify quantities measured and recorded, such as KWH, KW, cubic feet, degrees Celsius, etc. UOMs are based on a specific service type.

Attributes used to define units of measure include the following:

•

Service Type : The type of service (electric, gas, etc.) measured by the UOM

•

Decimal Positions : The number of decimal places used when sending usage transaction service quantities for this UOM to Oracle Utilities Customer Care and Billing by way of the base package Usage Transaction Outbound Message

•

Allowed on Measuring Component : A flag that indicates if the UOM is allowed on Measuring Components

•

Measures Peak Quantity : A flag that indicates if the UOM is used to measure peak quantities or not. An example of a UOM that measures peak quantities is kilowatts (KW).

•

Magnitude : A number that indicates the relative size of the UOM as compared to a single unit of the UOM specified under "Base Unit of Measure." For example, megawatt hours (MWH) have a magnitude of 1,000 as compared to a single kilowatt hour (KWH).

•

Base Unit of Measure : The UOM upon which the current UOM is based. Used in conjunction with magnitude. For example, the base unit of measure for megawatt hours (MWH) with a magnitude of 1,000 would be kilowatt hours (KWH).

General Admin Data

General admin data are types of data used by multiple functional areas.

Exception Types

Exception types define the properties common to many exceptions.

When creating validation, editing, and estimation (VEE) rules, you might create an exception type for each VEE rule. You might also create more general exception types, such as "Insufficient Data" to be used to signify that a measurement didn't have sufficient data for the VEE rule to execute.

Factors

Factor are a centrally stored set of values for use in validation rules, bill determinants calculations, and other processes.

A factor can have different values depending upon some definable attribute of a system object, such as customer size associated with a service point. Examples of factors can include minimum/maximum thresholds, loss factors, etc. Classes of factors are defined that can have numeric values (as in the above examples), or values pointing to profile measuring components, or VEE groups.

A factor's values are effective-dated values - either a number, a profile measuring component, a VEE group, or some custom-defined value - assigned to a factor and associated to the value of some attribute of a system object. For example, consider a service point that can be classified as residential, commercial, or industrial. The tolerance percentage by which a customer's consumption can exceed last month's consumption can be based on the service point category. For this example, factor values for a single factor called "tolerance percentage" could be: Residential - 20% Commercial - 10% Industrial - 5%.

Service Providers

Service providers are external entities that serve various roles relative to the application.

Service providers can include head-end systems, billing systems to which the application sends bill determinant data, market participants in a deregulated environment, outage management systems that receive meter event data from the application, or other parties that require or provide information to the system.

Service Quantity Identifiers

Service Quantity Identifiers (SQI) are used to further distinguish between measured quantities that have identical UOM/TOU combinations, including situations in which the distinguishing identifier of a UOM is not accurately described as a TOU.

SQIs can also be used as a stand-alone representation of a service quantity that is not measured (one that is not properly described as a UOM) within a usage service quantity collection (such as a billing determinant).

Service Types

Service Types define specific types of service for which usage can be recorded and captured, such as electric, gas, steam, etc.

Time of Use

Time of Use (TOU) periods are modifiers for a given unit of measure that indicate a period of time during which a quantity has been used, such as On-Peak (meaning during a time when the greatest quantity of some consumable is being used), Off-Peak (meaning during a time when the least amount of some consumable is being used), etc.

Units of Measure

Units of Measure (UOM) identify quantities measured and recorded, such as KWH, KW, cubic feet, degrees Celsius, etc. UOMs are based on a specific service type.

Attributes used to define units of measure include the following:

•

Service Type : The type of service (electric, gas, etc.) measured by the UOM

•

Decimal Positions : The number of decimal places used when sending usage transaction service quantities for this UOM to Oracle Utilities Customer Care and Billing by way of the base package Usage Transaction Outbound Message

•

Allowed on Measuring Component : A flag that indicates if the UOM is allowed on Measuring Components

•

Measures Peak Quantity : A flag that indicates if the UOM is used to measure peak quantities or not. An example of a UOM that measures peak quantities is kilowatts (KW).

•

Magnitude : A number that indicates the relative size of the UOM as compared to a single unit of the UOM specified under "Base Unit of Measure." For example, megawatt hours (MWH) have a magnitude of 1,000 as compared to a single kilowatt hour (KWH).

•

Base Unit of Measure : The UOM upon which the current UOM is based. Used in conjunction with magnitude. For example, the base unit of measure for megawatt hours (MWH) with a magnitude of 1,000 would be kilowatt hours (KWH).

Device Management Admin Data

Device management admin data include data that defines "types" of device-related objects.

Device Configuration Types

Device configuration types define the properties of device configurations of this type, including the valid types of measuring components that can be configured for device using configurations of this type.

Device Types

Device types define information about a class of devices, including properties that apply to all devices of a type. Properties defined for a device type can be overridden for an individual device.

Manufacturers

Manufacturers are the companies that makes devices. A device's manufacturer is defined as an attribute of the device itself.

Each manufacturer can have zero or more models defined. Models for a single manufacturer can have diverse service types.

Measuring Component Types

Measuring component types define the most important properties of a measuring component.

Measuring component types define what a measuring component measures (KWH, temperature, etc.), how regularly it measure it, and whether it should be connected to a physical device, or if it's used as a scratchpad measuring component or an aggregator measuring component. Measuring component types also specify how the measuring component's final measurements should be stored, how the measuring component's user-defined values should be calculated, and specific rules governing validation, editing, and estimation (VEE) for measuring components of the type. In addition, measuring component types define display properties and valid attribute values for measuring components belonging to the type.

Some important characteristics defined for measuring component types include:

•

Value Identifiers : These store the values of UOM, TOU, and SQI that identify the measured amounts for measuring components of this type. Value identifiers specify the quantities stored on the measurement records for measuring components of this type.

•

Valid VEE Groups : These define the VEE groups considered valid for measuring components of this type.

•

Fallback VEE Groups : These define default VEE groups that can be used with all measuring components of this type. This alleviates the need to specify the same VEE groups on multiple measuring components of the same type. Each VEE group is designated a VEE group role that indicates when and how the VEE group is used (for initial load, manual override, or estimation).

•

Eligible Profile Factors (interval only) : These define the profile factors that are considered to be eligible for interval measuring components of this type. You can also specify one or more profile factors as a default.

•

Valid Profile Factors for Conversion from Scalar to Interval (scalar only) : These define the profile factors that are considered to be eligible for scalar measuring components of this type when converting scalar measurements to interval measurements. You can also specify one or more profile factors as a default.

•

Valid Scratchpad Measuring Component Types : These define the scratchpad measuring component types considered valid for measuring components of this type.

•

Display Properties : Defines how measurement data for measuring components of this type is displayed, including:

•

Display Configuration : Details related to how measurements are displayed, including the number of hours of data to display, the default TOU map used, the TOU by Day Profile factor used, and default measurement condition.

•

Event Bar Profiles : The event bar profiles used when displaying measurement data for measuring components of this type. Event bar profiles are defined as values for the 360 View Event Bar Profile extendable lookup.

•

Final Values Overlay Profiles : The final values overlay profiles used when displaying measurement data for measuring components of this type. Final values overlay profiles are defined as values for the Final Values Overlay Profile extendable lookup.

Measuring component types are described in more detail in Chapter 4: Devices, Measuring Components, and, Device Configurations.

Device Management Admin Data

Device management admin data include data that defines "types" of device-related objects.

Device Configuration Types

Device configuration types define the properties of device configurations of this type, including the valid types of measuring components that can be configured for device using configurations of this type.

Device Types

Device types define information about a class of devices, including properties that apply to all devices of a type. Properties defined for a device type can be overridden for an individual device.

Manufacturers

Manufacturers are the companies that makes devices. A device's manufacturer is defined as an attribute of the device itself.

Each manufacturer can have zero or more models defined. Models for a single manufacturer can have diverse service types.

Measuring Component Types

Measuring component types define the most important properties of a measuring component.

Measuring component types define what a measuring component measures (KWH, temperature, etc.), how regularly it measure it, and whether it should be connected to a physical device, or if it's used as a scratchpad measuring component or an aggregator measuring component. Measuring component types also specify how the measuring component's final measurements should be stored, how the measuring component's user-defined values should be calculated, and specific rules governing validation, editing, and estimation (VEE) for measuring components of the type. In addition, measuring component types define display properties and valid attribute values for measuring components belonging to the type.

Some important characteristics defined for measuring component types include:

•

Value Identifiers : These store the values of UOM, TOU, and SQI that identify the measured amounts for measuring components of this type. Value identifiers specify the quantities stored on the measurement records for measuring components of this type.

•

Valid VEE Groups : These define the VEE groups considered valid for measuring components of this type.

•

Fallback VEE Groups : These define default VEE groups that can be used with all measuring components of this type. This alleviates the need to specify the same VEE groups on multiple measuring components of the same type. Each VEE group is designated a VEE group role that indicates when and how the VEE group is used (for initial load, manual override, or estimation).

•

Eligible Profile Factors (interval only) : These define the profile factors that are considered to be eligible for interval measuring components of this type. You can also specify one or more profile factors as a default.

•

Valid Profile Factors for Conversion from Scalar to Interval (scalar only) : These define the profile factors that are considered to be eligible for scalar measuring components of this type when converting scalar measurements to interval measurements. You can also specify one or more profile factors as a default.

•

Valid Scratchpad Measuring Component Types : These define the scratchpad measuring component types considered valid for measuring components of this type.

•

Display Properties : Defines how measurement data for measuring components of this type is displayed, including:

•

Display Configuration : Details related to how measurements are displayed, including the number of hours of data to display, the default TOU map used, the TOU by Day Profile factor used, and default measurement condition.

•

Event Bar Profiles : The event bar profiles used when displaying measurement data for measuring components of this type. Event bar profiles are defined as values for the 360 View Event Bar Profile extendable lookup.

•

Final Values Overlay Profiles : The final values overlay profiles used when displaying measurement data for measuring components of this type. Final values overlay profiles are defined as values for the Final Values Overlay Profile extendable lookup.

Measuring component types are described in more detail in Chapter 4: Devices, Measuring Components, and, Device Configurations.

Device Management Admin Data

Device management admin data include data that defines "types" of device-related objects.

Device Configuration Types

Device configuration types define the properties of device configurations of this type, including the valid types of measuring components that can be configured for device using configurations of this type.

Device Types

Device types define information about a class of devices, including properties that apply to all devices of a type. Properties defined for a device type can be overridden for an individual device.

Manufacturers

Manufacturers are the companies that makes devices. A device's manufacturer is defined as an attribute of the device itself.

Each manufacturer can have zero or more models defined. Models for a single manufacturer can have diverse service types.

Measuring Component Types

Measuring component types define the most important properties of a measuring component.

Measuring component types define what a measuring component measures (KWH, temperature, etc.), how regularly it measure it, and whether it should be connected to a physical device, or if it's used as a scratchpad measuring component or an aggregator measuring component. Measuring component types also specify how the measuring component's final measurements should be stored, how the measuring component's user-defined values should be calculated, and specific rules governing validation, editing, and estimation (VEE) for measuring components of the type. In addition, measuring component types define display properties and valid attribute values for measuring components belonging to the type.

Some important characteristics defined for measuring component types include:

•

Value Identifiers : These store the values of UOM, TOU, and SQI that identify the measured amounts for measuring components of this type. Value identifiers specify the quantities stored on the measurement records for measuring components of this type.

•

Valid VEE Groups : These define the VEE groups considered valid for measuring components of this type.

•

Fallback VEE Groups : These define default VEE groups that can be used with all measuring components of this type. This alleviates the need to specify the same VEE groups on multiple measuring components of the same type. Each VEE group is designated a VEE group role that indicates when and how the VEE group is used (for initial load, manual override, or estimation).

•

Eligible Profile Factors (interval only) : These define the profile factors that are considered to be eligible for interval measuring components of this type. You can also specify one or more profile factors as a default.

•

Valid Profile Factors for Conversion from Scalar to Interval (scalar only) : These define the profile factors that are considered to be eligible for scalar measuring components of this type when converting scalar measurements to interval measurements. You can also specify one or more profile factors as a default.

•

Valid Scratchpad Measuring Component Types : These define the scratchpad measuring component types considered valid for measuring components of this type.

•

Display Properties : Defines how measurement data for measuring components of this type is displayed, including:

•

Display Configuration : Details related to how measurements are displayed, including the number of hours of data to display, the default TOU map used, the TOU by Day Profile factor used, and default measurement condition.

•

Event Bar Profiles : The event bar profiles used when displaying measurement data for measuring components of this type. Event bar profiles are defined as values for the 360 View Event Bar Profile extendable lookup.

•

Final Values Overlay Profiles : The final values overlay profiles used when displaying measurement data for measuring components of this type. Final values overlay profiles are defined as values for the Final Values Overlay Profile extendable lookup.

Measuring component types are described in more detail in Chapter 4: Devices, Measuring Components, and, Device Configurations.

Device Management Admin Data

Device management admin data include data that defines "types" of device-related objects.

Device Configuration Types

Device configuration types define the properties of device configurations of this type, including the valid types of measuring components that can be configured for device using configurations of this type.

Device Types

Device types define information about a class of devices, including properties that apply to all devices of a type. Properties defined for a device type can be overridden for an individual device.

Manufacturers

Manufacturers are the companies that makes devices. A device's manufacturer is defined as an attribute of the device itself.

Each manufacturer can have zero or more models defined. Models for a single manufacturer can have diverse service types.

Measuring Component Types

Measuring component types define the most important properties of a measuring component.

Measuring component types define what a measuring component measures (KWH, temperature, etc.), how regularly it measure it, and whether it should be connected to a physical device, or if it's used as a scratchpad measuring component or an aggregator measuring component. Measuring component types also specify how the measuring component's final measurements should be stored, how the measuring component's user-defined values should be calculated, and specific rules governing validation, editing, and estimation (VEE) for measuring components of the type. In addition, measuring component types define display properties and valid attribute values for measuring components belonging to the type.

Some important characteristics defined for measuring component types include:

•

Value Identifiers : These store the values of UOM, TOU, and SQI that identify the measured amounts for measuring components of this type. Value identifiers specify the quantities stored on the measurement records for measuring components of this type.

•

Valid VEE Groups : These define the VEE groups considered valid for measuring components of this type.

•

Fallback VEE Groups : These define default VEE groups that can be used with all measuring components of this type. This alleviates the need to specify the same VEE groups on multiple measuring components of the same type. Each VEE group is designated a VEE group role that indicates when and how the VEE group is used (for initial load, manual override, or estimation).

•

Eligible Profile Factors (interval only) : These define the profile factors that are considered to be eligible for interval measuring components of this type. You can also specify one or more profile factors as a default.

•

Valid Profile Factors for Conversion from Scalar to Interval (scalar only) : These define the profile factors that are considered to be eligible for scalar measuring components of this type when converting scalar measurements to interval measurements. You can also specify one or more profile factors as a default.

•

Valid Scratchpad Measuring Component Types : These define the scratchpad measuring component types considered valid for measuring components of this type.

•

Display Properties : Defines how measurement data for measuring components of this type is displayed, including:

•

Display Configuration : Details related to how measurements are displayed, including the number of hours of data to display, the default TOU map used, the TOU by Day Profile factor used, and default measurement condition.

•

Event Bar Profiles : The event bar profiles used when displaying measurement data for measuring components of this type. Event bar profiles are defined as values for the 360 View Event Bar Profile extendable lookup.

•

Final Values Overlay Profiles : The final values overlay profiles used when displaying measurement data for measuring components of this type. Final values overlay profiles are defined as values for the Final Values Overlay Profile extendable lookup.

Measuring component types are described in more detail in Chapter 4: Devices, Measuring Components, and, Device Configurations.

Device Management Admin Data

Device management admin data include data that defines "types" of device-related objects.

Device Configuration Types

Device configuration types define the properties of device configurations of this type, including the valid types of measuring components that can be configured for device using configurations of this type.

Device Types

Device types define information about a class of devices, including properties that apply to all devices of a type. Properties defined for a device type can be overridden for an individual device.

Manufacturers

Manufacturers are the companies that makes devices. A device's manufacturer is defined as an attribute of the device itself.

Each manufacturer can have zero or more models defined. Models for a single manufacturer can have diverse service types.

Measuring Component Types

Measuring component types define the most important properties of a measuring component.

Measuring component types define what a measuring component measures (KWH, temperature, etc.), how regularly it measure it, and whether it should be connected to a physical device, or if it's used as a scratchpad measuring component or an aggregator measuring component. Measuring component types also specify how the measuring component's final measurements should be stored, how the measuring component's user-defined values should be calculated, and specific rules governing validation, editing, and estimation (VEE) for measuring components of the type. In addition, measuring component types define display properties and valid attribute values for measuring components belonging to the type.

Some important characteristics defined for measuring component types include:

•

Value Identifiers : These store the values of UOM, TOU, and SQI that identify the measured amounts for measuring components of this type. Value identifiers specify the quantities stored on the measurement records for measuring components of this type.

•

Valid VEE Groups : These define the VEE groups considered valid for measuring components of this type.

•

Fallback VEE Groups : These define default VEE groups that can be used with all measuring components of this type. This alleviates the need to specify the same VEE groups on multiple measuring components of the same type. Each VEE group is designated a VEE group role that indicates when and how the VEE group is used (for initial load, manual override, or estimation).

•

Eligible Profile Factors (interval only) : These define the profile factors that are considered to be eligible for interval measuring components of this type. You can also specify one or more profile factors as a default.

•

Valid Profile Factors for Conversion from Scalar to Interval (scalar only) : These define the profile factors that are considered to be eligible for scalar measuring components of this type when converting scalar measurements to interval measurements. You can also specify one or more profile factors as a default.

•

Valid Scratchpad Measuring Component Types : These define the scratchpad measuring component types considered valid for measuring components of this type.

•

Display Properties : Defines how measurement data for measuring components of this type is displayed, including:

•

Display Configuration : Details related to how measurements are displayed, including the number of hours of data to display, the default TOU map used, the TOU by Day Profile factor used, and default measurement condition.

•

Event Bar Profiles : The event bar profiles used when displaying measurement data for measuring components of this type. Event bar profiles are defined as values for the 360 View Event Bar Profile extendable lookup.

•

Final Values Overlay Profiles : The final values overlay profiles used when displaying measurement data for measuring components of this type. Final values overlay profiles are defined as values for the Final Values Overlay Profile extendable lookup.

Measuring component types are described in more detail in Chapter 4: Devices, Measuring Components, and, Device Configurations.

Device Installation Admin Data

Device installation admin data includes data used to support the installation of devices.

Markets

Markets define the jurisdictions or regulatory environments in which a service point participates.

Markets also define market relationships for valid service providers and their roles within a market (distributor, etc.). While each service point specifies only one market, a utility may serve more than one market, and different service points throughout the utility's service territory can be linked to different markets.

Service Point Types

Service point types define a specific type of point at which service is delivered.

Specifically, service point types define how the application manages many aspects of the service point’s behavior. A service point type may have one or more valid device types defined that limit the types of devices that can be installed at service points of this type.

Contact Types

Contact types define the properties of a class of entities (businesses, persons).

Measurement Cycles

Measurement cycles define the schedule for manual meter reading of devices at service points in that cycle. Measurement cycles can have one or more associated routes used to collect measurements.

When used with smart meters, measurement cycles can also be configured to define when to create usage transactions for usage subscriptions associated to service points in the cycle.

Measurement Cycle Schedules

Measurement cycle schedules define the dates on which devices are scheduled to be read for a given measurement cycle and the routes used to collect measurements for the measurement cycle.

Device Installation Admin Data

Device installation admin data includes data used to support the installation of devices.

Markets

Markets define the jurisdictions or regulatory environments in which a service point participates.

Markets also define market relationships for valid service providers and their roles within a market (distributor, etc.). While each service point specifies only one market, a utility may serve more than one market, and different service points throughout the utility's service territory can be linked to different markets.

Service Point Types

Service point types define a specific type of point at which service is delivered.

Specifically, service point types define how the application manages many aspects of the service point’s behavior. A service point type may have one or more valid device types defined that limit the types of devices that can be installed at service points of this type.

Contact Types

Contact types define the properties of a class of entities (businesses, persons).

Measurement Cycles

Measurement cycles define the schedule for manual meter reading of devices at service points in that cycle. Measurement cycles can have one or more associated routes used to collect measurements.

When used with smart meters, measurement cycles can also be configured to define when to create usage transactions for usage subscriptions associated to service points in the cycle.

Measurement Cycle Schedules

Measurement cycle schedules define the dates on which devices are scheduled to be read for a given measurement cycle and the routes used to collect measurements for the measurement cycle.

Device Installation Admin Data

Device installation admin data includes data used to support the installation of devices.

Markets

Markets define the jurisdictions or regulatory environments in which a service point participates.

Markets also define market relationships for valid service providers and their roles within a market (distributor, etc.). While each service point specifies only one market, a utility may serve more than one market, and different service points throughout the utility's service territory can be linked to different markets.

Service Point Types

Service point types define a specific type of point at which service is delivered.

Specifically, service point types define how the application manages many aspects of the service point’s behavior. A service point type may have one or more valid device types defined that limit the types of devices that can be installed at service points of this type.

Contact Types

Contact types define the properties of a class of entities (businesses, persons).

Measurement Cycles

Measurement cycles define the schedule for manual meter reading of devices at service points in that cycle. Measurement cycles can have one or more associated routes used to collect measurements.

When used with smart meters, measurement cycles can also be configured to define when to create usage transactions for usage subscriptions associated to service points in the cycle.

Measurement Cycle Schedules

Measurement cycle schedules define the dates on which devices are scheduled to be read for a given measurement cycle and the routes used to collect measurements for the measurement cycle.

Device Installation Admin Data

Device installation admin data includes data used to support the installation of devices.

Markets

Markets define the jurisdictions or regulatory environments in which a service point participates.

Markets also define market relationships for valid service providers and their roles within a market (distributor, etc.). While each service point specifies only one market, a utility may serve more than one market, and different service points throughout the utility's service territory can be linked to different markets.

Service Point Types

Service point types define a specific type of point at which service is delivered.

Specifically, service point types define how the application manages many aspects of the service point’s behavior. A service point type may have one or more valid device types defined that limit the types of devices that can be installed at service points of this type.

Contact Types

Contact types define the properties of a class of entities (businesses, persons).

Measurement Cycles

Measurement cycles define the schedule for manual meter reading of devices at service points in that cycle. Measurement cycles can have one or more associated routes used to collect measurements.

When used with smart meters, measurement cycles can also be configured to define when to create usage transactions for usage subscriptions associated to service points in the cycle.

Measurement Cycle Schedules

Measurement cycle schedules define the dates on which devices are scheduled to be read for a given measurement cycle and the routes used to collect measurements for the measurement cycle.

Device Installation Admin Data

Device installation admin data includes data used to support the installation of devices.

Markets

Markets define the jurisdictions or regulatory environments in which a service point participates.

Markets also define market relationships for valid service providers and their roles within a market (distributor, etc.). While each service point specifies only one market, a utility may serve more than one market, and different service points throughout the utility's service territory can be linked to different markets.

Service Point Types

Service point types define a specific type of point at which service is delivered.

Specifically, service point types define how the application manages many aspects of the service point’s behavior. A service point type may have one or more valid device types defined that limit the types of devices that can be installed at service points of this type.

Contact Types

Contact types define the properties of a class of entities (businesses, persons).

Measurement Cycles

Measurement cycles define the schedule for manual meter reading of devices at service points in that cycle. Measurement cycles can have one or more associated routes used to collect measurements.

When used with smart meters, measurement cycles can also be configured to define when to create usage transactions for usage subscriptions associated to service points in the cycle.

Measurement Cycle Schedules

Measurement cycle schedules define the dates on which devices are scheduled to be read for a given measurement cycle and the routes used to collect measurements for the measurement cycle.

Device Installation Admin Data

Device installation admin data includes data used to support the installation of devices.

Markets

Markets define the jurisdictions or regulatory environments in which a service point participates.

Markets also define market relationships for valid service providers and their roles within a market (distributor, etc.). While each service point specifies only one market, a utility may serve more than one market, and different service points throughout the utility's service territory can be linked to different markets.

Service Point Types

Service point types define a specific type of point at which service is delivered.

Specifically, service point types define how the application manages many aspects of the service point’s behavior. A service point type may have one or more valid device types defined that limit the types of devices that can be installed at service points of this type.

Contact Types

Contact types define the properties of a class of entities (businesses, persons).

Measurement Cycles

Measurement cycles define the schedule for manual meter reading of devices at service points in that cycle. Measurement cycles can have one or more associated routes used to collect measurements.

When used with smart meters, measurement cycles can also be configured to define when to create usage transactions for usage subscriptions associated to service points in the cycle.

Measurement Cycle Schedules

Measurement cycle schedules define the dates on which devices are scheduled to be read for a given measurement cycle and the routes used to collect measurements for the measurement cycle.

Device Communication Admin Data

Device communication admin data includes data used to support communication with head-end systems.

Activity Types

Activity types define properties common to a specific type of activity.

Activity types include types of communications between an application and a head-end system, such as a connection requests, meter ping requests, or on-demand meter readings, as well as device event types.

Communication Types

Communication types define properties common to a specific type of communication.

Communication types include types of communications between an application and a head-end system, such as notifications (used to notify an head-end system of a command request), or message responses (sent from a head-end system to confirm receipt of a message).

Note: Communication types are applicable only with Oracle Utilities Smart Grid Gateway.

Device Event Types

Device event types define properties common to specific types of events.

Device event types represent different types of events that can take place relative to a device. Examples of device events include power outages, power restoration, tampering alerts, and other events.

Device event types can be defined by the following attributes:

•

Standard Event Name : the "standard" name of the event type in Smart Grid Gateway. Device vendors may have their own specific names for device events.

•

Device Event Category : a category (defined as an Extendable Lookup) used to group device event types.

•

Reporting Category : a category used to group device event types for reporting purposes.

•

Activity Type : the activity type for activities created for device events of this type.

Service Task Types

Service tasks types define properties common to specific types of service tasks.

Service task types represent types of tasks that can be performed by users of other Oracle Utilities applications, such Oracle Utilities Customer Self Service or Oracle Utilities Network Management System. Examples of service tasks include self service meter reads, in which users enter their own meter reads via the Customer Self Service application, and service issue monitor types used when determining if service investigation is needed for a service point.

Device Communication Admin Data

Device communication admin data includes data used to support communication with head-end systems.

Activity Types

Activity types define properties common to a specific type of activity.

Activity types include types of communications between an application and a head-end system, such as a connection requests, meter ping requests, or on-demand meter readings, as well as device event types.

Communication Types

Communication types define properties common to a specific type of communication.

Communication types include types of communications between an application and a head-end system, such as notifications (used to notify an head-end system of a command request), or message responses (sent from a head-end system to confirm receipt of a message).

Note: Communication types are applicable only with Oracle Utilities Smart Grid Gateway.

Device Event Types

Device event types define properties common to specific types of events.

Device event types represent different types of events that can take place relative to a device. Examples of device events include power outages, power restoration, tampering alerts, and other events.

Device event types can be defined by the following attributes:

•

Standard Event Name : the "standard" name of the event type in Smart Grid Gateway. Device vendors may have their own specific names for device events.

•

Device Event Category : a category (defined as an Extendable Lookup) used to group device event types.

•

Reporting Category : a category used to group device event types for reporting purposes.

•

Activity Type : the activity type for activities created for device events of this type.

Service Task Types

Service tasks types define properties common to specific types of service tasks.

Service task types represent types of tasks that can be performed by users of other Oracle Utilities applications, such Oracle Utilities Customer Self Service or Oracle Utilities Network Management System. Examples of service tasks include self service meter reads, in which users enter their own meter reads via the Customer Self Service application, and service issue monitor types used when determining if service investigation is needed for a service point.

Device Communication Admin Data

Device communication admin data includes data used to support communication with head-end systems.

Activity Types

Activity types define properties common to a specific type of activity.

Activity types include types of communications between an application and a head-end system, such as a connection requests, meter ping requests, or on-demand meter readings, as well as device event types.

Communication Types

Communication types define properties common to a specific type of communication.

Communication types include types of communications between an application and a head-end system, such as notifications (used to notify an head-end system of a command request), or message responses (sent from a head-end system to confirm receipt of a message).

Note: Communication types are applicable only with Oracle Utilities Smart Grid Gateway.

Device Event Types

Device event types define properties common to specific types of events.

Device event types represent different types of events that can take place relative to a device. Examples of device events include power outages, power restoration, tampering alerts, and other events.

Device event types can be defined by the following attributes:

•

Standard Event Name : the "standard" name of the event type in Smart Grid Gateway. Device vendors may have their own specific names for device events.

•

Device Event Category : a category (defined as an Extendable Lookup) used to group device event types.

•

Reporting Category : a category used to group device event types for reporting purposes.

•

Activity Type : the activity type for activities created for device events of this type.

Service Task Types

Service tasks types define properties common to specific types of service tasks.

Service task types represent types of tasks that can be performed by users of other Oracle Utilities applications, such Oracle Utilities Customer Self Service or Oracle Utilities Network Management System. Examples of service tasks include self service meter reads, in which users enter their own meter reads via the Customer Self Service application, and service issue monitor types used when determining if service investigation is needed for a service point.

Device Communication Admin Data

Device communication admin data includes data used to support communication with head-end systems.

Activity Types

Activity types define properties common to a specific type of activity.

Activity types include types of communications between an application and a head-end system, such as a connection requests, meter ping requests, or on-demand meter readings, as well as device event types.

Communication Types

Communication types define properties common to a specific type of communication.

Communication types include types of communications between an application and a head-end system, such as notifications (used to notify an head-end system of a command request), or message responses (sent from a head-end system to confirm receipt of a message).

Note: Communication types are applicable only with Oracle Utilities Smart Grid Gateway.

Device Event Types

Device event types define properties common to specific types of events.

Device event types represent different types of events that can take place relative to a device. Examples of device events include power outages, power restoration, tampering alerts, and other events.

Device event types can be defined by the following attributes:

•

Standard Event Name : the "standard" name of the event type in Smart Grid Gateway. Device vendors may have their own specific names for device events.

•

Device Event Category : a category (defined as an Extendable Lookup) used to group device event types.

•

Reporting Category : a category used to group device event types for reporting purposes.

•

Activity Type : the activity type for activities created for device events of this type.

Service Task Types

Service tasks types define properties common to specific types of service tasks.

Service task types represent types of tasks that can be performed by users of other Oracle Utilities applications, such Oracle Utilities Customer Self Service or Oracle Utilities Network Management System. Examples of service tasks include self service meter reads, in which users enter their own meter reads via the Customer Self Service application, and service issue monitor types used when determining if service investigation is needed for a service point.

Device Communication Admin Data

Device communication admin data includes data used to support communication with head-end systems.

Activity Types

Activity types define properties common to a specific type of activity.

Activity types include types of communications between an application and a head-end system, such as a connection requests, meter ping requests, or on-demand meter readings, as well as device event types.

Communication Types

Communication types define properties common to a specific type of communication.

Communication types include types of communications between an application and a head-end system, such as notifications (used to notify an head-end system of a command request), or message responses (sent from a head-end system to confirm receipt of a message).

Note: Communication types are applicable only with Oracle Utilities Smart Grid Gateway.

Device Event Types

Device event types define properties common to specific types of events.

Device event types represent different types of events that can take place relative to a device. Examples of device events include power outages, power restoration, tampering alerts, and other events.

Device event types can be defined by the following attributes:

•

Standard Event Name : the "standard" name of the event type in Smart Grid Gateway. Device vendors may have their own specific names for device events.

•

Device Event Category : a category (defined as an Extendable Lookup) used to group device event types.

•

Reporting Category : a category used to group device event types for reporting purposes.

•

Activity Type : the activity type for activities created for device events of this type.

Service Task Types

Service tasks types define properties common to specific types of service tasks.

Service task types represent types of tasks that can be performed by users of other Oracle Utilities applications, such Oracle Utilities Customer Self Service or Oracle Utilities Network Management System. Examples of service tasks include self service meter reads, in which users enter their own meter reads via the Customer Self Service application, and service issue monitor types used when determining if service investigation is needed for a service point.

Admin Setup Reference Tables

This section lists and describes all objects that must be defined as part of the setup process for Oracle Utilities Smart Grid Gateway. It identifies the order in which objects should be defined and any prerequisites for setup.

Note : All basic Framework setup, including system and database setup and any modifications or extensions to base business objects, must have been completed before beginning setup tasks for Oracle Utilities Smart Grid Gateway. See the Framework documentation for more information.

Setup Sequence

In the setup tables that follow, the Sequence column displays the following codes:

L1 = Object has no setup prerequisites and should be defined before L2-L6 objects.

L2 = Object has some L1 prerequisites and should be defined after all L1 objects have been defined and before L3 objects.

L3 = Object should be defined after all L1 and L2 objects have been defined.

L4 = Object should be defined after all L1, L2, and L3 objects have been defined.

L5 = Object should be defined after all L1, L2, L3, and L4 objects have been defined.

Administration Setup and Maintenance

To access the maintenance portals for the objects in this section, do one of the following:

•

If you are using functional menus, select Admin Menu>[ Functional Menu ]>[ object name ]

•

If you are using alphabetical menus, select Admin Menu>[ object name]

The [ Functional Menu] and [object name] are provided in the appropriate columns in the following tables.

Application Framework Setup

Seq

Object

Functional Menu

Description

Prerequisites

L1

Country

General

Your organization's country.

None

L1

Currency

Financial

Your organization's native currency.

None

L1

Display Profile

General

Controls how dates, times, and numbers displayed.

None

L1

Language

General

The language to use for this implementation.

None

L1

Time Zone

General

Your organization’s base time zone.

None

L1

To Do Role

General

Used to associate users with To Do entries.

None

L1

Work Calendar

General

The work calendar for your organization, which identifies your public holidays

None

L2

Installation Options

System

Control various aspects of the system. Refer to the Installation Options section earlier in this document.

Time Zone, Language, Currency

L2

Master Configuration

System

Enables an implementation to capture various types of information in the system.

L2

To Do Type

General

Used to define types of To Do Entries

To Do Role

L2

User

Security

Defines a user’s user groups, data access roles, portal preferences, default values, and To Do roles

Language, Display Profile, To Do Roles

L2

User Group

Security

A group of users who have the same degree of security access

User

Oracle Utilities Smart Grid Gateway Setup

Seq

Object

Functional Menu

Description

Prerequisites

L1

Activity Type

Communications

Defines properties common to a specific type of activity

None

L1

Communication Type

Communications

Define properties common to a specific type of communication

None

L1

Contact Type

Customer Information

Defines properties of a class of entities (businesses, persons)

None

L1

Device Event Type

Communications

Defines properties common to a speecific types of events

None

L1

Exception Type

Common

Defines properties common to exceptions of a specific type

None

L1

Factor

Common

Centrally stored sets of values for use in validation rules, bill determinants calculations, and other processes

None

L1

Market

Communications

Defines jurisdictions or regulatory environments in which a service point participates

None

L1

Measurement Cycle

Device Installation

Defines the schedule for manual meter reading of devices at service points in that cycle

None

L1

Measurement Cycle Schedule

Device Installation

Define the dates on which devices are scheduled to be read for a given measurement cycle

None

L1

Service Provider

Communications

External entities that serve various roles relative to the application (head-end systems, billing systems, market participants, outage management systems, etc.)

None

L1

Service Quantity Identifier

Common

Used to further distinguish between measured quantities that have identical UOM/TOU combinations

None

L1

Service Type

Common

Defines specific types of service for which usage can be recorded and captured (electric, gas, steam, etc.)

None

L2

Manufacturer

Device

Individual companies that makes devices. Manufacturers also reference models.

Service Type

L2

Unit of Measure

Common

Quantities measured and recorded by the system (CCF, KWH, KW, etc.)

Service Type

L3

Measuring Component Type*

Device

Defines the most important properties of a measuring component

Factor (Profile), Service Quantity Identifier, Service Type, Time of Use, Unit of Measure, VEE Group

L4

Device Configuration Type

Device

Defines properties of device configurations of a given type

Service Type, Measuring Component Type

L4

Device Type

Device

Defines information about a class of devices

Service Type, Device Configuration Type

L5

Service Point Type

Device Installation

Defines specific types of points at which service is delivered

Service Type, Device Type

* Measuring component types also reference other measuring component types, TOU maps, and extendable lookups.

Administration Setup and Maintenance

To access the maintenance portals for the objects in this section, do one of the following:

•

If you are using functional menus, select Admin Menu>[ Functional Menu ]>[ object name ]

•

If you are using alphabetical menus, select Admin Menu>[ object name]

The [ Functional Menu] and [object name] are provided in the appropriate columns in the following tables.

Application Framework Setup

Seq

Object

Functional Menu

Description

Prerequisites

L1

Country

General

Your organization's country.

None

L1

Currency

Financial

Your organization's native currency.

None

L1

Display Profile

General

Controls how dates, times, and numbers displayed.

None

L1

Language

General

The language to use for this implementation.

None

L1

Time Zone

General

Your organization’s base time zone.

None

L1

To Do Role

General

Used to associate users with To Do entries.

None

L1

Work Calendar

General

The work calendar for your organization, which identifies your public holidays

None

L2

Installation Options

System

Control various aspects of the system. Refer to the Installation Options section earlier in this document.

Time Zone, Language, Currency

L2

Master Configuration

System

Enables an implementation to capture various types of information in the system.

L2

To Do Type

General

Used to define types of To Do Entries

To Do Role

L2

User

Security

Defines a user’s user groups, data access roles, portal preferences, default values, and To Do roles

Language, Display Profile, To Do Roles

L2

User Group

Security

A group of users who have the same degree of security access

User

Oracle Utilities Smart Grid Gateway Setup

Seq

Object

Functional Menu

Description

Prerequisites

L1

Activity Type

Communications

Defines properties common to a specific type of activity

None

L1

Communication Type

Communications

Define properties common to a specific type of communication

None

L1

Contact Type

Customer Information

Defines properties of a class of entities (businesses, persons)

None

L1

Device Event Type

Communications

Defines properties common to a speecific types of events

None

L1

Exception Type

Common

Defines properties common to exceptions of a specific type

None

L1

Factor

Common

Centrally stored sets of values for use in validation rules, bill determinants calculations, and other processes

None

L1

Market

Communications

Defines jurisdictions or regulatory environments in which a service point participates

None

L1

Measurement Cycle

Device Installation

Defines the schedule for manual meter reading of devices at service points in that cycle

None

L1

Measurement Cycle Schedule

Device Installation

Define the dates on which devices are scheduled to be read for a given measurement cycle

None

L1

Service Provider

Communications

External entities that serve various roles relative to the application (head-end systems, billing systems, market participants, outage management systems, etc.)

None

L1

Service Quantity Identifier

Common

Used to further distinguish between measured quantities that have identical UOM/TOU combinations

None

L1

Service Type

Common

Defines specific types of service for which usage can be recorded and captured (electric, gas, steam, etc.)

None

L2

Manufacturer

Device

Individual companies that makes devices. Manufacturers also reference models.

Service Type

L2

Unit of Measure

Common

Quantities measured and recorded by the system (CCF, KWH, KW, etc.)

Service Type

L3

Measuring Component Type*

Device

Defines the most important properties of a measuring component

Factor (Profile), Service Quantity Identifier, Service Type, Time of Use, Unit of Measure, VEE Group

L4

Device Configuration Type

Device

Defines properties of device configurations of a given type

Service Type, Measuring Component Type

L4

Device Type

Device

Defines information about a class of devices

Service Type, Device Configuration Type

L5

Service Point Type

Device Installation

Defines specific types of points at which service is delivered

Service Type, Device Type

* Measuring component types also reference other measuring component types, TOU maps, and extendable lookups.

Administration Setup and Maintenance

To access the maintenance portals for the objects in this section, do one of the following:

•

If you are using functional menus, select Admin Menu>[ Functional Menu ]>[ object name ]

•

If you are using alphabetical menus, select Admin Menu>[ object name]

The [ Functional Menu] and [object name] are provided in the appropriate columns in the following tables.

Application Framework Setup

Seq

Object

Functional Menu

Description

Prerequisites

L1

Country

General

Your organization's country.

None

L1

Currency

Financial

Your organization's native currency.

None

L1

Display Profile

General

Controls how dates, times, and numbers displayed.

None

L1

Language

General

The language to use for this implementation.

None

L1

Time Zone

General

Your organization’s base time zone.

None

L1

To Do Role

General

Used to associate users with To Do entries.

None

L1

Work Calendar

General

The work calendar for your organization, which identifies your public holidays

None

L2

Installation Options

System

Control various aspects of the system. Refer to the Installation Options section earlier in this document.

Time Zone, Language, Currency

L2

Master Configuration

System

Enables an implementation to capture various types of information in the system.

L2

To Do Type

General

Used to define types of To Do Entries

To Do Role

L2

User

Security

Defines a user’s user groups, data access roles, portal preferences, default values, and To Do roles

Language, Display Profile, To Do Roles

L2

User Group

Security

A group of users who have the same degree of security access

User

Oracle Utilities Smart Grid Gateway Setup

Seq

Object

Functional Menu

Description

Prerequisites

L1

Activity Type

Communications

Defines properties common to a specific type of activity

None

L1

Communication Type

Communications

Define properties common to a specific type of communication

None

L1

Contact Type

Customer Information

Defines properties of a class of entities (businesses, persons)

None

L1

Device Event Type

Communications

Defines properties common to a speecific types of events

None

L1

Exception Type

Common

Defines properties common to exceptions of a specific type

None

L1

Factor

Common

Centrally stored sets of values for use in validation rules, bill determinants calculations, and other processes

None

L1

Market

Communications

Defines jurisdictions or regulatory environments in which a service point participates

None

L1

Measurement Cycle

Device Installation

Defines the schedule for manual meter reading of devices at service points in that cycle

None

L1

Measurement Cycle Schedule

Device Installation

Define the dates on which devices are scheduled to be read for a given measurement cycle

None

L1

Service Provider

Communications

External entities that serve various roles relative to the application (head-end systems, billing systems, market participants, outage management systems, etc.)

None

L1

Service Quantity Identifier

Common

Used to further distinguish between measured quantities that have identical UOM/TOU combinations

None

L1

Service Type

Common

Defines specific types of service for which usage can be recorded and captured (electric, gas, steam, etc.)

None

L2

Manufacturer

Device

Individual companies that makes devices. Manufacturers also reference models.

Service Type

L2

Unit of Measure

Common

Quantities measured and recorded by the system (CCF, KWH, KW, etc.)

Service Type

L3

Measuring Component Type*

Device

Defines the most important properties of a measuring component

Factor (Profile), Service Quantity Identifier, Service Type, Time of Use, Unit of Measure, VEE Group

L4

Device Configuration Type

Device

Defines properties of device configurations of a given type

Service Type, Measuring Component Type

L4

Device Type

Device

Defines information about a class of devices

Service Type, Device Configuration Type

L5

Service Point Type

Device Installation

Defines specific types of points at which service is delivered

Service Type, Device Type

* Measuring component types also reference other measuring component types, TOU maps, and extendable lookups.

Devices, Measuring Components, and Device Configurations

This chapter provides descriptions of devices, device configurations, and measuring components, including:

•

Understanding Devices, Measuring Components, and Device Configurations

•

Devices In Detail

•

Device Configurations In Detail

•

Measuring Components In Detail

•

Measuring Component Types In Detail

•

Configuring Devices, Measuring Components, and Device Configurations

Note : References to objects and options pre-fixed with "D2" are available only with Oracle Utilities Meter Data Management, and included for illustrative purposes only.

Understanding Devices, Measuring Components, and Device Configurations

This section provides an overview of devices, measuring components, and device configurations, including how they are used in the Service and Measurement Data Foundation and related products including Oracle Utilities Meter Data Management and Oracle Utilities Smart Grid Gateway.

Devices

Devices are physical or virtual objects that hold one or more measuring components that can produce data to be handled by the system. While most devices are meters, an implementation might set up devices for every asset that measures or monitors resource usage. For example, a device could be set up to record average daily temperature (if temperature plays a part in usage calculations). Examples of devices include meters, substations, transformers, demand response devices, weather stations, etc.

Communication Components

Communication components are devices attached to meters. A communication component may handle electronic transmission of measurement data, events, and commands in situations in which the underlying meter is not capable or not enabled to handle this data. Devices of this sort are sometimes referred to as ERT (Electronic Receiver/Transmitter) meters, or communication modules (for example, the term "gas module" may refer to a communication module attached to a gas meter).

Devices

Devices are physical or virtual objects that hold one or more measuring components that can produce data to be handled by the system. While most devices are meters, an implementation might set up devices for every asset that measures or monitors resource usage. For example, a device could be set up to record average daily temperature (if temperature plays a part in usage calculations). Examples of devices include meters, substations, transformers, demand response devices, weather stations, etc.

Communication Components

Communication components are devices attached to meters. A communication component may handle electronic transmission of measurement data, events, and commands in situations in which the underlying meter is not capable or not enabled to handle this data. Devices of this sort are sometimes referred to as ERT (Electronic Receiver/Transmitter) meters, or communication modules (for example, the term "gas module" may refer to a communication module attached to a gas meter).

Measuring Components

Measuring components are single points for which data will be received and stored in the system.

Types of Measuring Components

A measuring component can be associated to a physical device, which can have one or more measuring components, or it can be "virtual" or "stand-alone," meaning that it is not associated to a physical device. The Service and Measurement Data Foundation supports the following types of measuring components:

•

Physical : Physical measuring components are those that physically exist, and that are linked to a device that can be configured differently over time. Interval channels and scalar registers are examples of physical measuring components.

Note : The terms register and channel are synonyms for measuring component.

•

Standalone : A standalone measuring component is used to record measurements for something that does not have a physical presence.For example, you might create a standalone measuring component to record the average daily temperature supplied by a weather station.

•

Scratchpad : User create scratchpad measuring components to experiment with measurement manipulation functions before applying the functions to a physical or standalone measuring component. Examples of measurement manipulation might include experimenting with the impact of executing the "spike smooth" function on an initial measurement, or adding or removing intervals to or from the measurement. Scratchpad measuring components provide users with a means to manipulate "scratchpad" measurement data without affecting existing "live" measurement data.

•

Aggregator : An aggregator measuring component holds summarized usage from other measuring components. For example, aggregator measuring components could be configured to hold total consumption for each postal code within a service territory.

Head-end system processing statistics used by Oracle Utilities Smart Grid Gateway are stored as aggregated measurements for aggregator measuring components.

Scalar vs. Interval

Beyond the four types described above, measuring components generally fall into one of two primary classes of: scalar measuring components, and interval measuring components.

•

Scalar measuring components are measured at unpredictable intervals. For example, "once-a-month" is not a predictable interval as the amount of time between reads in unpredictable and inconsistent.

Scalar measuring components are typically read manually

•

Interval measuring components are measured at predictable intervals, such as every 15 minutes, every 30 minutes, every hour, etc.

The term Seconds-per-interval (SPI) is used to define the size of an interval measuring component's intervals.

Note : A device may have any combination of interval and/or scalar measuring components

Measuring Component Measurements

Measuring components are configured to measure specific types of quantities. These include:

•

Unit of Measure : The unit of measure for the quantity being recorded. Examples include kilo-watt hours (kWh), kilo-watts (kW), therms, cubic feet (CCF), temperature (Farenheit or Celsius), etc.

•

Time of Use : Modifiers for a given unit of measure that indicate a period of time during which a quantity has been used, such as On-Peak (meaning during a time when the greatest quantity of some consumable is being used), Off-Peak (meaning during a time when the least amount of some consumable is being used), etc.

•

Service Quantity Identifiers : Used to further distinguish between measured quantities that have identical UOM/TOU combinations, including situations in which the distinguishing identifier of a UOM is not accurately described as a TOU. Generally, SQI is only used when multiple measuring components measure the same thing, but in different ways. A meter that measures both generation KWH and consumption KWH could use SQIs to differentiate between the two.

The combination of UOM, TOU and SQI define what a measuring component measures. TOU and SQI are optional, but UOM must be defined for all measuring components.

For example, consider a meter (as illustrated in the image below) with two measuring components, both measuring the same unit of measure (kWh), but each measuring component measures consumption in different time of use (TOU) periods (peak and off-peak).

Another example might be a meter that records both generated KWH and consumed KWH. This meter would be configured to measure both UOM and SQI.

A measurement is recorded each time a measuring component is measured. This means that for a meter with two measuring components that is read once a month, two measurements, one for each measuring component, would be recorded each month.

Subtractive vs. Consumptive Measurements

Another attribute that defines how measuring components measure quantities is the distinction between subtractive and consumptive measuring components.

A subtractive measuring component’s usage is equal to the current measurement (also known as the Stop or End Measurement or Reading) minus the previous measurement (also known as the Start Measurement or Reading). To put this more simply:

Most residential scalar KWH meters are subtractive. The table below lists a series of measurements for a subtractive measuring component.

Date

KWH (Measurement)

Usage

01/01/2010

0

01/31/2010

1000

1000 KWH

03/02/2010

1789

789 KWH

04/01/2010

2700

911 KWH

A consumptive measuring component’s usage is equal to its current measurement. Consumptive measuring components are often used to measure demand, such as KW. The table below lists a series of measurements for a consumptive measuring component.

Date

KW (Measurement)

Usage

01/01/2010

0

01/31/2010

10

10 KW

03/02/2010

6

6 KW

04/01/2010

5

5 KW

Interval measuring components can also be considered consumptive, in that the consumption value of each individual interval is equal to its measurement.

Interval vs. Scalar Measurements

As noted above, interval measuring components record measurements every interval, defined by the measuring component’s SPI (seconds per interval). For interval measuring components, measurements are only allowed on these time boundaries. For example, measurements for an interval measuring component with an SPI of 900 (15 minutes) on January 1, 2010 might be as follows:

Date

Time

KWH

01/01/2010

10:00 AM

0

01/01/2010

10:15 AM

10

01/01/2010

10:30 AM

6

01/01/2010

10:45 AM

5

In contrast to interval measuring components, scalar measuring components are read at unpredictable (and often inconsistent) intervals and are allowed at any point in time. In practice, scalar measuring components are read monthly, bimonthly, quarterly, etc. For example, measurements for an scalar measuring component from January 1, 2010 through April 1, 2010 might be as follows

Date

KWH (Measurement)

01/01/2010

0

01/31/2010

1000

03/02/2010

1789

04/01/2010

2700

Note that interval and scalar measuring components can exist on the single meter. For these types of meters, the scalar measuring component is typically used to verify and validate the interval measurements. For example, the sum of all the interval measurements within a measurement period should equal the scalar measurement for the same period.

Device vs. Measuring Component Attributes

The distinction between attributes used to define devices and measuring components is important when creating devices and measuring components as part of an implementation. For example, if you identify additional attributes you wish to capture, it’s import to store those attributes in the most appropriate place.

Devices have attributes that are applicable to the physical object, and that are the same regardless of the number of measuring components on the device. For example:

•

The type of device

•

Manufacturer and Model

•

Serial Number

•

Badge Number

•

Head-End System (for smart meters)

Measuring components have attributes that may differ for each measuring component on a device, for example:

•

The type of measuring component (which in turn defines the measuring component’s UOM, TOU, SQI, whether it is scalar or interval (and its SPI), and others

•

Channel ID (for interval channel measuring components)

•

Channel (or Register) multiplier (a value by which the measured consumption is multiplied to derive usage)

•

Validation, Editing, and Estimation groups used when validating initial measurement data for the measuring component.

Measuring Components

Measuring components are single points for which data will be received and stored in the system.

Types of Measuring Components

A measuring component can be associated to a physical device, which can have one or more measuring components, or it can be "virtual" or "stand-alone," meaning that it is not associated to a physical device. The Service and Measurement Data Foundation supports the following types of measuring components:

•

Physical : Physical measuring components are those that physically exist, and that are linked to a device that can be configured differently over time. Interval channels and scalar registers are examples of physical measuring components.

Note : The terms register and channel are synonyms for measuring component.

•

Standalone : A standalone measuring component is used to record measurements for something that does not have a physical presence.For example, you might create a standalone measuring component to record the average daily temperature supplied by a weather station.

•

Scratchpad : User create scratchpad measuring components to experiment with measurement manipulation functions before applying the functions to a physical or standalone measuring component. Examples of measurement manipulation might include experimenting with the impact of executing the "spike smooth" function on an initial measurement, or adding or removing intervals to or from the measurement. Scratchpad measuring components provide users with a means to manipulate "scratchpad" measurement data without affecting existing "live" measurement data.

•

Aggregator : An aggregator measuring component holds summarized usage from other measuring components. For example, aggregator measuring components could be configured to hold total consumption for each postal code within a service territory.

Head-end system processing statistics used by Oracle Utilities Smart Grid Gateway are stored as aggregated measurements for aggregator measuring components.

Scalar vs. Interval

Beyond the four types described above, measuring components generally fall into one of two primary classes of: scalar measuring components, and interval measuring components.

•

Scalar measuring components are measured at unpredictable intervals. For example, "once-a-month" is not a predictable interval as the amount of time between reads in unpredictable and inconsistent.

Scalar measuring components are typically read manually

•

Interval measuring components are measured at predictable intervals, such as every 15 minutes, every 30 minutes, every hour, etc.

The term Seconds-per-interval (SPI) is used to define the size of an interval measuring component's intervals.

Note : A device may have any combination of interval and/or scalar measuring components

Measuring Component Measurements

Measuring components are configured to measure specific types of quantities. These include:

•

Unit of Measure : The unit of measure for the quantity being recorded. Examples include kilo-watt hours (kWh), kilo-watts (kW), therms, cubic feet (CCF), temperature (Farenheit or Celsius), etc.

•

Time of Use : Modifiers for a given unit of measure that indicate a period of time during which a quantity has been used, such as On-Peak (meaning during a time when the greatest quantity of some consumable is being used), Off-Peak (meaning during a time when the least amount of some consumable is being used), etc.

•

Service Quantity Identifiers : Used to further distinguish between measured quantities that have identical UOM/TOU combinations, including situations in which the distinguishing identifier of a UOM is not accurately described as a TOU. Generally, SQI is only used when multiple measuring components measure the same thing, but in different ways. A meter that measures both generation KWH and consumption KWH could use SQIs to differentiate between the two.

The combination of UOM, TOU and SQI define what a measuring component measures. TOU and SQI are optional, but UOM must be defined for all measuring components.

For example, consider a meter (as illustrated in the image below) with two measuring components, both measuring the same unit of measure (kWh), but each measuring component measures consumption in different time of use (TOU) periods (peak and off-peak).

Another example might be a meter that records both generated KWH and consumed KWH. This meter would be configured to measure both UOM and SQI.

A measurement is recorded each time a measuring component is measured. This means that for a meter with two measuring components that is read once a month, two measurements, one for each measuring component, would be recorded each month.

Subtractive vs. Consumptive Measurements

Another attribute that defines how measuring components measure quantities is the distinction between subtractive and consumptive measuring components.

A subtractive measuring component’s usage is equal to the current measurement (also known as the Stop or End Measurement or Reading) minus the previous measurement (also known as the Start Measurement or Reading). To put this more simply:

Most residential scalar KWH meters are subtractive. The table below lists a series of measurements for a subtractive measuring component.

Date

KWH (Measurement)

Usage

01/01/2010

0

01/31/2010

1000

1000 KWH

03/02/2010

1789

789 KWH

04/01/2010

2700

911 KWH

A consumptive measuring component’s usage is equal to its current measurement. Consumptive measuring components are often used to measure demand, such as KW. The table below lists a series of measurements for a consumptive measuring component.

Date

KW (Measurement)

Usage

01/01/2010

0

01/31/2010

10

10 KW

03/02/2010

6

6 KW

04/01/2010

5

5 KW

Interval measuring components can also be considered consumptive, in that the consumption value of each individual interval is equal to its measurement.

Interval vs. Scalar Measurements

As noted above, interval measuring components record measurements every interval, defined by the measuring component’s SPI (seconds per interval). For interval measuring components, measurements are only allowed on these time boundaries. For example, measurements for an interval measuring component with an SPI of 900 (15 minutes) on January 1, 2010 might be as follows:

Date

Time

KWH

01/01/2010

10:00 AM

0

01/01/2010

10:15 AM

10

01/01/2010

10:30 AM

6

01/01/2010

10:45 AM

5

In contrast to interval measuring components, scalar measuring components are read at unpredictable (and often inconsistent) intervals and are allowed at any point in time. In practice, scalar measuring components are read monthly, bimonthly, quarterly, etc. For example, measurements for an scalar measuring component from January 1, 2010 through April 1, 2010 might be as follows

Date

KWH (Measurement)

01/01/2010

0

01/31/2010

1000

03/02/2010

1789

04/01/2010

2700

Note that interval and scalar measuring components can exist on the single meter. For these types of meters, the scalar measuring component is typically used to verify and validate the interval measurements. For example, the sum of all the interval measurements within a measurement period should equal the scalar measurement for the same period.

Device vs. Measuring Component Attributes

The distinction between attributes used to define devices and measuring components is important when creating devices and measuring components as part of an implementation. For example, if you identify additional attributes you wish to capture, it’s import to store those attributes in the most appropriate place.

Devices have attributes that are applicable to the physical object, and that are the same regardless of the number of measuring components on the device. For example:

•

The type of device

•

Manufacturer and Model

•

Serial Number

•

Badge Number

•

Head-End System (for smart meters)

Measuring components have attributes that may differ for each measuring component on a device, for example:

•

The type of measuring component (which in turn defines the measuring component’s UOM, TOU, SQI, whether it is scalar or interval (and its SPI), and others

•

Channel ID (for interval channel measuring components)

•

Channel (or Register) multiplier (a value by which the measured consumption is multiplied to derive usage)

•

Validation, Editing, and Estimation groups used when validating initial measurement data for the measuring component.

Measuring Components

Measuring components are single points for which data will be received and stored in the system.

Types of Measuring Components

A measuring component can be associated to a physical device, which can have one or more measuring components, or it can be "virtual" or "stand-alone," meaning that it is not associated to a physical device. The Service and Measurement Data Foundation supports the following types of measuring components:

•

Physical : Physical measuring components are those that physically exist, and that are linked to a device that can be configured differently over time. Interval channels and scalar registers are examples of physical measuring components.

Note : The terms register and channel are synonyms for measuring component.

•

Standalone : A standalone measuring component is used to record measurements for something that does not have a physical presence.For example, you might create a standalone measuring component to record the average daily temperature supplied by a weather station.

•

Scratchpad : User create scratchpad measuring components to experiment with measurement manipulation functions before applying the functions to a physical or standalone measuring component. Examples of measurement manipulation might include experimenting with the impact of executing the "spike smooth" function on an initial measurement, or adding or removing intervals to or from the measurement. Scratchpad measuring components provide users with a means to manipulate "scratchpad" measurement data without affecting existing "live" measurement data.

•

Aggregator : An aggregator measuring component holds summarized usage from other measuring components. For example, aggregator measuring components could be configured to hold total consumption for each postal code within a service territory.

Head-end system processing statistics used by Oracle Utilities Smart Grid Gateway are stored as aggregated measurements for aggregator measuring components.

Scalar vs. Interval

Beyond the four types described above, measuring components generally fall into one of two primary classes of: scalar measuring components, and interval measuring components.

•

Scalar measuring components are measured at unpredictable intervals. For example, "once-a-month" is not a predictable interval as the amount of time between reads in unpredictable and inconsistent.

Scalar measuring components are typically read manually

•

Interval measuring components are measured at predictable intervals, such as every 15 minutes, every 30 minutes, every hour, etc.

The term Seconds-per-interval (SPI) is used to define the size of an interval measuring component's intervals.

Note : A device may have any combination of interval and/or scalar measuring components

Measuring Component Measurements

Measuring components are configured to measure specific types of quantities. These include:

•

Unit of Measure : The unit of measure for the quantity being recorded. Examples include kilo-watt hours (kWh), kilo-watts (kW), therms, cubic feet (CCF), temperature (Farenheit or Celsius), etc.

•

Time of Use : Modifiers for a given unit of measure that indicate a period of time during which a quantity has been used, such as On-Peak (meaning during a time when the greatest quantity of some consumable is being used), Off-Peak (meaning during a time when the least amount of some consumable is being used), etc.

•

Service Quantity Identifiers : Used to further distinguish between measured quantities that have identical UOM/TOU combinations, including situations in which the distinguishing identifier of a UOM is not accurately described as a TOU. Generally, SQI is only used when multiple measuring components measure the same thing, but in different ways. A meter that measures both generation KWH and consumption KWH could use SQIs to differentiate between the two.

The combination of UOM, TOU and SQI define what a measuring component measures. TOU and SQI are optional, but UOM must be defined for all measuring components.

For example, consider a meter (as illustrated in the image below) with two measuring components, both measuring the same unit of measure (kWh), but each measuring component measures consumption in different time of use (TOU) periods (peak and off-peak).

Another example might be a meter that records both generated KWH and consumed KWH. This meter would be configured to measure both UOM and SQI.

A measurement is recorded each time a measuring component is measured. This means that for a meter with two measuring components that is read once a month, two measurements, one for each measuring component, would be recorded each month.

Subtractive vs. Consumptive Measurements

Another attribute that defines how measuring components measure quantities is the distinction between subtractive and consumptive measuring components.

A subtractive measuring component’s usage is equal to the current measurement (also known as the Stop or End Measurement or Reading) minus the previous measurement (also known as the Start Measurement or Reading). To put this more simply:

Most residential scalar KWH meters are subtractive. The table below lists a series of measurements for a subtractive measuring component.

Date

KWH (Measurement)

Usage

01/01/2010

0

01/31/2010

1000

1000 KWH

03/02/2010

1789

789 KWH

04/01/2010

2700

911 KWH

A consumptive measuring component’s usage is equal to its current measurement. Consumptive measuring components are often used to measure demand, such as KW. The table below lists a series of measurements for a consumptive measuring component.

Date

KW (Measurement)

Usage

01/01/2010

0

01/31/2010

10

10 KW

03/02/2010

6

6 KW

04/01/2010

5

5 KW

Interval measuring components can also be considered consumptive, in that the consumption value of each individual interval is equal to its measurement.

Interval vs. Scalar Measurements

As noted above, interval measuring components record measurements every interval, defined by the measuring component’s SPI (seconds per interval). For interval measuring components, measurements are only allowed on these time boundaries. For example, measurements for an interval measuring component with an SPI of 900 (15 minutes) on January 1, 2010 might be as follows:

Date

Time

KWH

01/01/2010

10:00 AM

0

01/01/2010

10:15 AM

10

01/01/2010

10:30 AM

6

01/01/2010

10:45 AM

5

In contrast to interval measuring components, scalar measuring components are read at unpredictable (and often inconsistent) intervals and are allowed at any point in time. In practice, scalar measuring components are read monthly, bimonthly, quarterly, etc. For example, measurements for an scalar measuring component from January 1, 2010 through April 1, 2010 might be as follows

Date

KWH (Measurement)

01/01/2010

0

01/31/2010

1000

03/02/2010

1789

04/01/2010

2700

Note that interval and scalar measuring components can exist on the single meter. For these types of meters, the scalar measuring component is typically used to verify and validate the interval measurements. For example, the sum of all the interval measurements within a measurement period should equal the scalar measurement for the same period.

Device vs. Measuring Component Attributes

The distinction between attributes used to define devices and measuring components is important when creating devices and measuring components as part of an implementation. For example, if you identify additional attributes you wish to capture, it’s import to store those attributes in the most appropriate place.

Devices have attributes that are applicable to the physical object, and that are the same regardless of the number of measuring components on the device. For example:

•

The type of device

•

Manufacturer and Model

•

Serial Number

•

Badge Number

•

Head-End System (for smart meters)

Measuring components have attributes that may differ for each measuring component on a device, for example:

•

The type of measuring component (which in turn defines the measuring component’s UOM, TOU, SQI, whether it is scalar or interval (and its SPI), and others

•

Channel ID (for interval channel measuring components)

•

Channel (or Register) multiplier (a value by which the measured consumption is multiplied to derive usage)

•

Validation, Editing, and Estimation groups used when validating initial measurement data for the measuring component.

Measuring Components

Measuring components are single points for which data will be received and stored in the system.

Types of Measuring Components

A measuring component can be associated to a physical device, which can have one or more measuring components, or it can be "virtual" or "stand-alone," meaning that it is not associated to a physical device. The Service and Measurement Data Foundation supports the following types of measuring components:

•

Physical : Physical measuring components are those that physically exist, and that are linked to a device that can be configured differently over time. Interval channels and scalar registers are examples of physical measuring components.

Note : The terms register and channel are synonyms for measuring component.

•

Standalone : A standalone measuring component is used to record measurements for something that does not have a physical presence.For example, you might create a standalone measuring component to record the average daily temperature supplied by a weather station.

•

Scratchpad : User create scratchpad measuring components to experiment with measurement manipulation functions before applying the functions to a physical or standalone measuring component. Examples of measurement manipulation might include experimenting with the impact of executing the "spike smooth" function on an initial measurement, or adding or removing intervals to or from the measurement. Scratchpad measuring components provide users with a means to manipulate "scratchpad" measurement data without affecting existing "live" measurement data.

•

Aggregator : An aggregator measuring component holds summarized usage from other measuring components. For example, aggregator measuring components could be configured to hold total consumption for each postal code within a service territory.

Head-end system processing statistics used by Oracle Utilities Smart Grid Gateway are stored as aggregated measurements for aggregator measuring components.

Scalar vs. Interval

Beyond the four types described above, measuring components generally fall into one of two primary classes of: scalar measuring components, and interval measuring components.

•

Scalar measuring components are measured at unpredictable intervals. For example, "once-a-month" is not a predictable interval as the amount of time between reads in unpredictable and inconsistent.

Scalar measuring components are typically read manually

•

Interval measuring components are measured at predictable intervals, such as every 15 minutes, every 30 minutes, every hour, etc.

The term Seconds-per-interval (SPI) is used to define the size of an interval measuring component's intervals.

Note : A device may have any combination of interval and/or scalar measuring components

Measuring Component Measurements

Measuring components are configured to measure specific types of quantities. These include:

•

Unit of Measure : The unit of measure for the quantity being recorded. Examples include kilo-watt hours (kWh), kilo-watts (kW), therms, cubic feet (CCF), temperature (Farenheit or Celsius), etc.

•

Time of Use : Modifiers for a given unit of measure that indicate a period of time during which a quantity has been used, such as On-Peak (meaning during a time when the greatest quantity of some consumable is being used), Off-Peak (meaning during a time when the least amount of some consumable is being used), etc.

•

Service Quantity Identifiers : Used to further distinguish between measured quantities that have identical UOM/TOU combinations, including situations in which the distinguishing identifier of a UOM is not accurately described as a TOU. Generally, SQI is only used when multiple measuring components measure the same thing, but in different ways. A meter that measures both generation KWH and consumption KWH could use SQIs to differentiate between the two.

The combination of UOM, TOU and SQI define what a measuring component measures. TOU and SQI are optional, but UOM must be defined for all measuring components.

For example, consider a meter (as illustrated in the image below) with two measuring components, both measuring the same unit of measure (kWh), but each measuring component measures consumption in different time of use (TOU) periods (peak and off-peak).

Another example might be a meter that records both generated KWH and consumed KWH. This meter would be configured to measure both UOM and SQI.

A measurement is recorded each time a measuring component is measured. This means that for a meter with two measuring components that is read once a month, two measurements, one for each measuring component, would be recorded each month.

Subtractive vs. Consumptive Measurements

Another attribute that defines how measuring components measure quantities is the distinction between subtractive and consumptive measuring components.

A subtractive measuring component’s usage is equal to the current measurement (also known as the Stop or End Measurement or Reading) minus the previous measurement (also known as the Start Measurement or Reading). To put this more simply:

Most residential scalar KWH meters are subtractive. The table below lists a series of measurements for a subtractive measuring component.

Date

KWH (Measurement)

Usage

01/01/2010

0

01/31/2010

1000

1000 KWH

03/02/2010

1789

789 KWH

04/01/2010

2700

911 KWH

A consumptive measuring component’s usage is equal to its current measurement. Consumptive measuring components are often used to measure demand, such as KW. The table below lists a series of measurements for a consumptive measuring component.

Date

KW (Measurement)

Usage

01/01/2010

0

01/31/2010

10

10 KW

03/02/2010

6

6 KW

04/01/2010

5

5 KW

Interval measuring components can also be considered consumptive, in that the consumption value of each individual interval is equal to its measurement.

Interval vs. Scalar Measurements

As noted above, interval measuring components record measurements every interval, defined by the measuring component’s SPI (seconds per interval). For interval measuring components, measurements are only allowed on these time boundaries. For example, measurements for an interval measuring component with an SPI of 900 (15 minutes) on January 1, 2010 might be as follows:

Date

Time

KWH

01/01/2010

10:00 AM

0

01/01/2010

10:15 AM

10

01/01/2010

10:30 AM

6

01/01/2010

10:45 AM

5

In contrast to interval measuring components, scalar measuring components are read at unpredictable (and often inconsistent) intervals and are allowed at any point in time. In practice, scalar measuring components are read monthly, bimonthly, quarterly, etc. For example, measurements for an scalar measuring component from January 1, 2010 through April 1, 2010 might be as follows

Date

KWH (Measurement)

01/01/2010

0

01/31/2010

1000

03/02/2010

1789

04/01/2010

2700

Note that interval and scalar measuring components can exist on the single meter. For these types of meters, the scalar measuring component is typically used to verify and validate the interval measurements. For example, the sum of all the interval measurements within a measurement period should equal the scalar measurement for the same period.

Device vs. Measuring Component Attributes

The distinction between attributes used to define devices and measuring components is important when creating devices and measuring components as part of an implementation. For example, if you identify additional attributes you wish to capture, it’s import to store those attributes in the most appropriate place.

Devices have attributes that are applicable to the physical object, and that are the same regardless of the number of measuring components on the device. For example:

•

The type of device

•

Manufacturer and Model

•

Serial Number

•

Badge Number

•

Head-End System (for smart meters)

Measuring components have attributes that may differ for each measuring component on a device, for example:

•

The type of measuring component (which in turn defines the measuring component’s UOM, TOU, SQI, whether it is scalar or interval (and its SPI), and others

•

Channel ID (for interval channel measuring components)

•

Channel (or Register) multiplier (a value by which the measured consumption is multiplied to derive usage)

•

Validation, Editing, and Estimation groups used when validating initial measurement data for the measuring component.

Device Configurations

A measuring component’s attributes can change over time. Device configurations record how a device's measuring components look at an instant in time. A new device configuration is required whenever a device's measuring components are reconfigured. For example, if the register multiplier on a measuring component changes as of June 1, 2010, the device would require a new device configurations dated 1-Jun-2010 to reflect the change.

Note that device configurations don’t typically capture the changed information, but instead indicate that changes of some sort have taken place on one or more of the device’s measuring components.

Communication Components and Device Configurations

Communication components can have device configurations (one or more over time) with measuring components to record initial measurements, and its device configuration can be installed at a service point (the "Communication Component Install Event business object is used for install events for components.

Device Configurations

A measuring component’s attributes can change over time. Device configurations record how a device's measuring components look at an instant in time. A new device configuration is required whenever a device's measuring components are reconfigured. For example, if the register multiplier on a measuring component changes as of June 1, 2010, the device would require a new device configurations dated 1-Jun-2010 to reflect the change.

Note that device configurations don’t typically capture the changed information, but instead indicate that changes of some sort have taken place on one or more of the device’s measuring components.

Communication Components and Device Configurations

Communication components can have device configurations (one or more over time) with measuring components to record initial measurements, and its device configuration can be installed at a service point (the "Communication Component Install Event business object is used for install events for components.

Devices In Detail

This section provides details concerning the device objects supplied as part of the base package. This information illustrates how the base package objects were designed, and can serve as the basis for any custom devices you create as part of your implementation. This section includes:

•

A description of the D1-DEVICE maintenance object

•

Lists of the base package device business objects, including "lite" business objects

•

Details concerning device-specific configuration options

•

A sample device business object (D1-SmartMeter)

Maintenance Object - D1-DEVICE

Device business objects use the D1-DEVICE maintenance object. The table below outlines some of the details of this maintenance object.

Option/Field

Description

Maintenance Object

D1-DEVICE

Description

Device

Service Name

D1-DEVICE (Device Maintenance)

Tables

•

D1_DVC (Device) - Primary

•

D1_DVC_CHAR (Device Characteristics) - Child

•

D1_DVC_IDENTIFIER (Device Identifier) - Child

•

D1_DVC_LOG (Device Log) - Child

•

D1_DVC_LOG_PARM (Device Log Parameter) - Child

Use the Maintenance Object portal and the Application Viewer to view more details about this maintenance object.

Service and Measurement Data Foundation Base Package Device Business Objects

The Service and Measurement Data Foundation base package includes the following device business objects:

Business Object Name

Description

D1-CommComponentDevice

Communication Component Device

Instances of this business object represent individual communication components defined in the system.

D1-ManualMeter

Manual Meter

Instances of this business object represent individual manual meters defined in the system.

D1-SmartMeter

Smart Meter

Instances of this business object represent individual smart meters defined in the system.

The Service and Measurement Data Foundation base package includes the following "lite" device business objects:

Business Object Name

Description

D1-DeviceDetailsLITE

Device LITE

D1-DeviceIDsLire

Lite BO to Get AMI ID Type dynamically

D1-DeviceIdentifierLite

Device Identifiers LITE

D1-DeviceLite

Device LITE

D1-DeviceLiteAMI

BO to Get AMI related details for Deive

D1-DeviceParentLite

Device Parent LITE

The Service and Measurement Data Foundation base package includes the following additionl device business objects:

Business Object Name

Description

D1-SynchronizationAddDevice

Device Synchronization Add (used when adding a new device as a result of a data synchronization request)

Configuration Options

This section outlines specific configuration options, such as business object options, system events, and other options used by device business objects.

Business Object Options

Device business objects can make use of the following business object options:

•

Install Event BO : This option identifies the install event business object to use when installing device configurations for devices defined by this business object.

For example, for the D1-SmartMeter device, this option is set to D1-SmartMeterInstallEvent, meaning that any time a device configuration for the D1-SmartMeter device is installed, the install event business object used will be D1-SmartMeterInstallEvent.

•

Synchronization Add BO : This option identifies the business object to use when adding new devices as a result of a data synchronization request.

•

Valid Command Request BO : This option defines the valid commands available for the device, and the activity business object to use for each command. This option is used with Oracle Utilities Smart Grid Gateway and can be defined multiple times for the same device, once for each command supported by the device.

For example, for the D1-SmartMeter device, this option is defined seven times, once for each of the following commands: On-Demand Read - Interval, On-Demand Read - Scalar, Device Status Check, Remove Connect, Remote Disconnect, Device Commission, and Device Decomission.

Configuration Options

This section outlines specific configuration options, such as business object options, system events, and other options used by device business objects.

Business Object Options

Device business objects can make use of the following business object options:

•

Install Event BO : This option identifies the install event business object to use when installing device configurations for devices defined by this business object.

For example, for the D1-SmartMeter device, this option is set to D1-SmartMeterInstallEvent, meaning that any time a device configuration for the D1-SmartMeter device is installed, the install event business object used will be D1-SmartMeterInstallEvent.

•

Synchronization Add BO : This option identifies the business object to use when adding new devices as a result of a data synchronization request.

•

Valid Command Request BO : This option defines the valid commands available for the device, and the activity business object to use for each command. This option is used with Oracle Utilities Smart Grid Gateway and can be defined multiple times for the same device, once for each command supported by the device.

For example, for the D1-SmartMeter device, this option is defined seven times, once for each of the following commands: On-Demand Read - Interval, On-Demand Read - Scalar, Device Status Check, Remove Connect, Remote Disconnect, Device Commission, and Device Decomission.

Example Device - D1-SmartMeter

This section lists some of the details of the D1-SmartMeter device business object.

Option/Field

Description

Business Object

D1-SmartMeter

Description

Smart Meter

Maintenance Object

D1-DEVICE (Device)

Application Service

D1-SMARTMTRBOAS (Smart Meter BO)

Instance Control

Allow New Instances

Options

•

Device Category: D1SM (Smart)

•

Install Event BO: D1-SmartMeterInstallEvent (Smart Meter Installation Event)

•

Synchronization Add BO: D1-SynchronizationAddBO (Device Synchroniation Add)

•

Valid Command Request BOs:

•

D1-OnDemandReadInterval (On-Demand Read Interval)

•

D1-OnDemandReadScalar (On-Demand Read Scalar)

•

D1-DeviceStatusCheck (Device Status Check)

•

D1-RemoteConnect (Remote Connect)

•

D1-RemoteDisconnect (Remote Disconnect)

•

D1-DeviceCommission (Device Commission)

•

D1-DeviceDecommission (Device Decommission)

•

Display UI Map: D1-SmartMeterDisplay (Smart Meter - Display)

•

Portal Navigation Option: d1dvcTabMenu (Device)

•

Display Map Service Script: D1-RtSmMtrDs (Smart Meter - Retrieve Details for Display)

•

Maintenance UI Map: D1-SmartMeterMaint (Smart Meter - Maintenance)

Algorithms

•

Information: D1-SMARTINFO (Smart Meter Information)

•

Validation: D1-VALRETDT (Validate Device Retirement Date)

Lifecycle

•

Active (Initial)

•

Retired (Final)

Use the Business Object portal to view additional details concerning this business object.

Device Configurations In Detail

This section provides details concerning the device configurations supplied as part of the base package. This information illustrates how the base package objects were designed, and can serve as the basis for any custom device configurations you create as part of your implementation. This section includes:

•

A description of the D1-DVCCONFIG maintenance object

•

Lists of the base package device configuration business objects, including "lite" business objects

•

A sample device configuration business object (D1-DeviceConfiguration)

Maintenance Object - D1-DVCCONFIG

Device configuration business objects use the D1-DVCCONFIG maintenance object. The table below outlines some of the details of this maintenance object.

Option/Field

Description

Maintenance Object

D1-DVCCONFIG

Description

Device Configuration

Service Name

D1-DVCCONFIG (Device Configuration Maintenance)

Tables

•

D1_DVC_CFG (Device Configuration) - Primary

•

D1_DVC_CFG_CHAR (Device Configuration Characteristics - Child

•

D1_DVC_CFG_LOG (Device Configuration Log) - Child

•

D1_DVC_CFG_LOG_PARM (Device Configuration Log Parameter) - Child

Use the Maintenance Object portal and the Application Viewer to view more details about this maintenance object.

Service and Measurement Data Foundation Base Package Device Configuration Business Objects

The Service and Measurement Data Foundation base package includes the following device configuration business objects:

Business Object Name

Description

D1-DeviceConfiguration

Device Configuration

Instances of the business object represent individual device configurations defined in the system.

The Service and Measurement Data Foundation base package includes the following "lite" device configuration business objects:

Business Object Name

Description

D1-DeviceConfigParentLITE

Device Configuration Parent LITE

D1-DeviceConfigurationLite

Device Configuration LITE

The Service and Measurement Data Foundation base package includes the following additionl device business objects:

Business Object Name

Description

D1-SynchronizationAddDC

Device Configuration Synchronization Add (used when adding a new device configuration as a result of a data synchronization request)

Configuration Options

This section outlines specific configuration options, such as business object options, system events, and other options used by device configuration business objects.

Business Object Options

Device configuration business objects can make use of the following business object options:

•

Synchronization Add BO : This option identifies the business object to use when adding new device configurations as a result of a data synchronization request.

Configuration Options

This section outlines specific configuration options, such as business object options, system events, and other options used by device configuration business objects.

Business Object Options

Device configuration business objects can make use of the following business object options:

•

Synchronization Add BO : This option identifies the business object to use when adding new device configurations as a result of a data synchronization request.

Example Device Configuration - D1-DeviceConfiguration

The table below lists the details of the D1-DeviceConfiguration device configuration business object.

Option

Description

Business Object

D1-DeviceConfiguration

Description

Device Configuration

Maintenance Object

D1-DVCCONFIG (Device Configuration)

Application Service

D1-DVCCONFIGBOAS (Device Configuration BO)

Instance Control

Allow New Instances

Options

•

Synchronization Add BO: D1-SynchronizationAddDC (Device Configuration Synchronization Add)

•

Display UI Map: D1-DeviceConfigDisplay (Device Configuration- Display)

•

Portal Navigation Option: d1dvcfgTabMenu (Device Configuration)

•

Display Map Service Script: D1-D1-RtDvcCfgD (Device Configuration - Retreive Details for Display)

•

Maintenance UI Map: D1-DeviceConfigMaint (Device Configuration- Maintenance)

Algorithms

•

Information: D1-DVCOINFO (Device Configuration Information)

•

Pre-Processing: D1-DELMC (Delete Associated Measuring Components)

•

Pre-Processing: D1-DEFTIMZON (Default Time Zone value based on Installation Option)

•

Validation: D1-INSTDCVAL (Earlier Installed Device Configuration)

•

Validation: D1-VALTIMZON (Validates BO Time Zone value against Installation Option)

Lifecycle

•

Pending (Initial)

•

Active (Final)

Use the Business Object portal to view additional details concerning this business object.

Measuring Component Types In Detail

This section provides details concerning the measuring component type objects supplied as part of the base package. This information illustrates how the base package objects were designed, and can serve as the basis for any custom measuring component type objects you create as part of your implementation. This section includes:

•

A description of the D1-MCTYPE maintenance object

•

Lists of the base package measuring component type business objects, including "lite" business objects

•

Details concerning measuring component type-specific configuration options

•

A sample measuring component type business object (D1-IntervalChannelTypePhysical)

Maintenance Object - D1-MCTYPE

Measuring component type business objects use the D1-MCTYPE maintenance object. The table below outlines some of the details of this maintenance object.

Option/Field

Description

Maintenance Object

D1-MCTYPE

Description

Measuring Component Type

Service Name

D1-MCTYPE (Measuring Component Type Maintenance)

Tables

•

D1_MEASR_COMP_TYPE (Measuring Component Type) - Primary

•

D1_MC_TYPE_VALUE_IDENTIFIER (Measuring Component Type Value Identifier) - Child

•

D1_MC_TYPE_VALUE_IDENTIFIER_L (MC Type Value Identifier Language) - Child

•

D1_MEASR_COMP_TYPE_CHAR (Measuring Component Type Characteristics) - Child

•

D1_MEASR_COMP_TYPE_L (Measuring Component Type Language) - Child

•

D1_MEASR_COMP_TYPE_VEE_GRP (Measuring Component Type VEE Group) - Child

•

D1_MEASR_COMP_TYPE_FBK_VEE_GRP (Measuring Component Type Fallback VEE Grp) - Child

Use the Maintenance Object portal and the Application Viewer to view more details about this maintenance object.

Service and Measurement Data Foundation Base Package Measuring Component Type Business Objects

The Service and Measurement Data Foundation base package includes the following measuring component type business objects:

Business Object Name

Description

D1-ActivityStatsAggType

Activity Statistics Aggregator Type

Instances of this business object represent individual activty statistics aggregator measuring component types defined in the system.

Activty Statistics Aggregators are used to track statistics related to device event and measurement uploads.

D1-AutoReadRegisterType

Auto-Read Register Type

Instances of this business object represent individual auto-read register measuring component types defined in the system.

Auto-Read Regiters are automatically read on a regular basis but the system receives only one measurement at a time, meaning one measurement per Initial Measurement. These types of measuring components are categorized as scalar rather than interval, even though Initial Measurements are received on a regular basis.

D1-GenericMCType

Generic MC Type (used as a parent measuring component type)

D1-IntervalChannelTypePhysical

Interval Channel Type - Physical

Instances of this business object represent individual physical interval channel measuring component types defined in the system.

D1-IntervalChannelTypeScratchp

Interval Channel Type - Scratchpad

Instances of this business object represent individual scratchpad interval channel measuring component types defined in the system.

D1-RegisterTypePhysical

Register Type

Instances of this business object represent individual physical register measuring component types defined in the system.

The Service and Measurement Data Foundation base package includes the following "lite" measuring component type business objects:

Business Object Name

Description

D1-MCTypeEstimateParmsLiteBO

MC Type Periodic Estimation LITE

D1-MCTypeLite

MC Type Lite

D1-MCTypeMainLite

Measuring Component Type LITE

D1-MCTypeParentLITE

Measuring Component Type Parent LITE

D1-MeasuringCompTypeLite

Measuring Component Type LITE

The Service and Measurement Data Foundation base package includes the following additional measuring component type business objects:

Business Object Name

Description

D1-MCTypeValueIdentifiers

Measuring Component Type Value Identifiers (used to retrieve the value identifiers of a measuring component type)

D1-MeasuringCompTypeBundlingBO

Bundling BO for Measuring Component Type

D1-MeasuringCompTypePhysicalBO

Physical BO for Measuring Component Type

Configuration Options

This section outlines specific configuration options, such as business object options, system events, and other options used by measuring component type business objects.

System Events

Measuring component type business objects can make use of the following system events:

•

Calculate Interval Consumption : This system event defines the algorithm used to calculate interval consumption for measuring components based on this measuring component type.

•

Calculate Scalar Consumption : This system event defines the algorithm used to calculate scalar consumption for measuring components based of this type.

Other Options

Measuring component types define many attributes of the measuring components of that type. These options are specified when creating measuring component types based on a measuring component type business object, and include the following:

Value Identifiers

Value identifiers store the values of UOM, TOU, and SQI that identify the measured amounts for measuring components of this type. Value identifiers specify the quantities stored on the measurement records for measuring components of this type.

Value identifiers must also specify a Value Derivation Algorithm based on the D1-DERIVAQTY Algorithm Type (Derive a quantity using a formula). This algorithm is used to derive measurement elements by applying a formula to calculate a value.

VEE Groups (Valid and Fallback)

VEE Groups define the validation, editing, and estimation rules to be applied to initial measurement data for measuring components of this type.

•

Valid VEE Groups : These define the VEE groups considered valid for measuring components of this type.

•

Fallback VEE Groups : These define default VEE groups that can be used with all measuring components of this type. This alleviates the need to specify the same VEE groups on multiple measuring components of the same type. Each VEE group is designated a VEE group role that indicates when and how the VEE group is used (for initial load, manual override, or estimation).

Profile Factors

Profile factors are factors of type profile used when displaying initial measurement data on the Measuring Component portal of the 360 Degree View. Measuring component types reference the following types of profile factors:

•

Eligible Profile Factors (interval only) : These define the profile factors that are considered to be eligible for interval measuring components of this type. You can also specify one or more profile factors as a default.

•

Valid Profile Factors for Conversion from Scalar to Interval (scalar only) : These define the profile factors that are considered to be eligible for scalar measuring components of this type when converting scalar measurements to interval measurements. You can also specify one or more profile factors as a default.

Valid Scratchpad Measuring Component Types

These define the scratchpad measuring component types considered valid for measuring components of this type.

Display Properties

Measuring component types reference the following display properties:

•

Event Bar Profiles : used when displaying measurement data for measuring components of this type. Event bar profiles are business objects defined as values for the "360 View Event Bar Profile" extendable lookup (D1-360EventBarProfile).

•

Final Values Overlay Profiles : This display option is used when displaying final measurement data for measuring components of this type. Final values overlay profiles are business objects defined as values for the "Final Values Overlay Profile" extendable lookup (D1-FinalValuesOverlayProfile).

Configuration Options

This section outlines specific configuration options, such as business object options, system events, and other options used by measuring component type business objects.

System Events

Measuring component type business objects can make use of the following system events:

•

Calculate Interval Consumption : This system event defines the algorithm used to calculate interval consumption for measuring components based on this measuring component type.

•

Calculate Scalar Consumption : This system event defines the algorithm used to calculate scalar consumption for measuring components based of this type.

Other Options

Measuring component types define many attributes of the measuring components of that type. These options are specified when creating measuring component types based on a measuring component type business object, and include the following:

Value Identifiers

Value identifiers store the values of UOM, TOU, and SQI that identify the measured amounts for measuring components of this type. Value identifiers specify the quantities stored on the measurement records for measuring components of this type.

Value identifiers must also specify a Value Derivation Algorithm based on the D1-DERIVAQTY Algorithm Type (Derive a quantity using a formula). This algorithm is used to derive measurement elements by applying a formula to calculate a value.

VEE Groups (Valid and Fallback)

VEE Groups define the validation, editing, and estimation rules to be applied to initial measurement data for measuring components of this type.

•

Valid VEE Groups : These define the VEE groups considered valid for measuring components of this type.

•

Fallback VEE Groups : These define default VEE groups that can be used with all measuring components of this type. This alleviates the need to specify the same VEE groups on multiple measuring components of the same type. Each VEE group is designated a VEE group role that indicates when and how the VEE group is used (for initial load, manual override, or estimation).

Profile Factors

Profile factors are factors of type profile used when displaying initial measurement data on the Measuring Component portal of the 360 Degree View. Measuring component types reference the following types of profile factors:

•

Eligible Profile Factors (interval only) : These define the profile factors that are considered to be eligible for interval measuring components of this type. You can also specify one or more profile factors as a default.

•

Valid Profile Factors for Conversion from Scalar to Interval (scalar only) : These define the profile factors that are considered to be eligible for scalar measuring components of this type when converting scalar measurements to interval measurements. You can also specify one or more profile factors as a default.

Valid Scratchpad Measuring Component Types

These define the scratchpad measuring component types considered valid for measuring components of this type.

Display Properties

Measuring component types reference the following display properties:

•

Event Bar Profiles : used when displaying measurement data for measuring components of this type. Event bar profiles are business objects defined as values for the "360 View Event Bar Profile" extendable lookup (D1-360EventBarProfile).

•

Final Values Overlay Profiles : This display option is used when displaying final measurement data for measuring components of this type. Final values overlay profiles are business objects defined as values for the "Final Values Overlay Profile" extendable lookup (D1-FinalValuesOverlayProfile).

Configuration Options

This section outlines specific configuration options, such as business object options, system events, and other options used by measuring component type business objects.

System Events

Measuring component type business objects can make use of the following system events:

•

Calculate Interval Consumption : This system event defines the algorithm used to calculate interval consumption for measuring components based on this measuring component type.

•

Calculate Scalar Consumption : This system event defines the algorithm used to calculate scalar consumption for measuring components based of this type.

Other Options

Measuring component types define many attributes of the measuring components of that type. These options are specified when creating measuring component types based on a measuring component type business object, and include the following:

Value Identifiers

Value identifiers store the values of UOM, TOU, and SQI that identify the measured amounts for measuring components of this type. Value identifiers specify the quantities stored on the measurement records for measuring components of this type.

Value identifiers must also specify a Value Derivation Algorithm based on the D1-DERIVAQTY Algorithm Type (Derive a quantity using a formula). This algorithm is used to derive measurement elements by applying a formula to calculate a value.

VEE Groups (Valid and Fallback)

VEE Groups define the validation, editing, and estimation rules to be applied to initial measurement data for measuring components of this type.

•

Valid VEE Groups : These define the VEE groups considered valid for measuring components of this type.

•

Fallback VEE Groups : These define default VEE groups that can be used with all measuring components of this type. This alleviates the need to specify the same VEE groups on multiple measuring components of the same type. Each VEE group is designated a VEE group role that indicates when and how the VEE group is used (for initial load, manual override, or estimation).

Profile Factors

Profile factors are factors of type profile used when displaying initial measurement data on the Measuring Component portal of the 360 Degree View. Measuring component types reference the following types of profile factors:

•

Eligible Profile Factors (interval only) : These define the profile factors that are considered to be eligible for interval measuring components of this type. You can also specify one or more profile factors as a default.

•

Valid Profile Factors for Conversion from Scalar to Interval (scalar only) : These define the profile factors that are considered to be eligible for scalar measuring components of this type when converting scalar measurements to interval measurements. You can also specify one or more profile factors as a default.

Valid Scratchpad Measuring Component Types

These define the scratchpad measuring component types considered valid for measuring components of this type.

Display Properties

Measuring component types reference the following display properties:

•

Event Bar Profiles : used when displaying measurement data for measuring components of this type. Event bar profiles are business objects defined as values for the "360 View Event Bar Profile" extendable lookup (D1-360EventBarProfile).

•

Final Values Overlay Profiles : This display option is used when displaying final measurement data for measuring components of this type. Final values overlay profiles are business objects defined as values for the "Final Values Overlay Profile" extendable lookup (D1-FinalValuesOverlayProfile).

Example Measuring Component Type - D1-IntervalChannelTypePhysical

The table below lists the details of the D1-IntervalChannelTypePhysical measuring component type business object.

Option

Description

Business Object

D1-IntervalChannelTypePhysical

Description

Interval Channel Type - Physical

Maintenance Object

D1-MCTYPE (Measuring Component Type)

Application Service

D1-MCTYPE (Measuring Component Type MO)

Instance Control

Allow New Instances

Options

•

Display UI Map: D1-IntervalChannelTypeDisplay (Interval Channel Type - Display)

•

Portal Navigation Option: d1mctypeTabMenu (Measuring Component Type)

•

Maintenance UI Map: D1-IntervalChannelTypeMaint (Interval Channel Type - Maintenance)

Algorithms

•

Calculate Interval Consumption: D1-IN-CNSUMP (Calculate Interval Consumption)

•

Validation: D1-MCTVIVAL (Validate UOM/TOU/SQI Combination)

•

Validation: D1-INTSCRVAL (Validate List of Scratchpad Measuring Component Types)

•

Validation: D1-DEFTOUVAL (Validate Interval Size of TOU Map)

•

Validation: D1-ELPRFTVAL (Validate Factors for Eligible Profile Factors)

•

Validation: D1-FNVALOVAL (Validate Final Values Overlay Profiles)

•

Validation: D1-EVTBARVAL (Validate Event Bar Profiles)

•

Validation: D1-HRDATAVAL (Hours of Data to Display Validation)

Use the Business Object portal to view additional details concerning this business object.

Measuring Components In Detail

This section provides details concerning the measuring components supplied as part of the base package. This information illustrates how the base package objects were designed, and can serve as the basis for any custom measuring components you create as part of your implementation. This section includes:

•

A description of the D1-MEASRCOMP maintenance object

•

Lists of the base package measuring component business objects, including "lite" business objects

•

Details concerning measuring component-specific configuration options

•

A sample measuring component business object (D1-IntervalChannel)

•

Lists of base package measurement functions including the BPA Script, Service Script, and a brief description of each

Maintenance Object - D1-MEASRCOMP

Measuring component business objects use the D1-MEASRCOMP maintenance object. The table below outlines some of the details of this maintenance object.

Option/Field

Description

Maintenance Object

D1-MEASRCOMP

Description

Measuring Component

Service Name

D1-MEASRCOMP (Measuring Component Maintenance)

Tables

•

D1_MEASR_COMP (Measuring Component) - Primary

•

D1_MEASR_COMP_CHAR (Measuring Component Characteristics) - Child

•

D1_MEASR_COMP_IDENTIFIER (Measuring Component Identifier) - Child

•

D1_MEASR_COMP_LOG (Measuring Component Log) - Child

•

D1_MEASR_COMP_LOG_PARM (Measuring Component Log Parameter) - Child

•

D1_MEASR_COMP_REL (Related Measuring Component) - Child

•

D1_MEASR_COMP_VEE_GROUP (Measuring Component VEE Group) - Child

Use the Maintenance Object portal and the Application Viewer to view more details about this maintenance object.

Service and Measurement Data Foundation Base Package Measuring Component Business Objects

The Service and Measurement Data Foundation base package includes the following measuring component business objects:

Business Object Name

Description

D1-IntervalChannel

Interval Channel

Instance of this business object represent individual interval channel measuring components defined in the system.

D1-IntervalScratchpad

Interval Scratchpad

Instance of this business object represent individual interval scratchpad measuring components defined in the system.

D1-PayloadStatsAggEvent

Payload Statistics Aggregator Event

Instance of this business object represent individual event payload statistics saggregator measuring components defined in the system.

D1-PayloadStatsAggIMD

Payload Statistics Aggregator - IMD

Instance of this business object represent individual measurement payload statistics saggregator measuring components defined in the system.

D1-Register

Register

Instance of this business object represent individual register measuring components defined in the system.

D1-RegsiterAutoRead

Register - Auto-Read

Instance of this business object represent individual auto-read register measuring components defined in the system.

D1-StatsAggregator

Statistics Aggregator (used as a parent to payload statistics aggregators)..

The Service and Measurement Data Foundation base package includes the following "lite" measuring component business objects:

Business Object Name

Description

D1-MCLatestMeasrDttm

Measuring Component Lite BO for Latest Measurement Date/Time

D1-MCLite

Measuring Component LITE

D1-MCScratchpadLite

MC Lite Scratchpad

D1-MCStandAlone

Measuring Component Standalone Lite

D1-MeasuringCompParentLITE

Measuring Component Parent LITE

The Service and Measurement Data Foundation base package includes the following additional measuring component business objects:

Business Object Name

Description

D1-SynchronizationAddMC

Measuring Component Synchronization Add (used when adding a new measuring component as a result of a data synchronization request)

Configuration Options

This section outlines specific configuration options, such as business object options, system events, and other options used by measuring component business objects.

Business Object Options

Measuring component business objects can make use of the following business object options:

•

Estimation Initial Measurement Data BO : This option identifies the initial measurement data business object to use when creating new "estimation" type initial measurement data for the measuring component.

For example, for the D1-IntervalChannel measuring component business object, this option is set to D1-EstimationIMDInterval, meaning that new "estimation" type initial measurement data for measuring components based on the D1-IntervalChannel business object would use the D1-EstimationIMDInterval business object.

•

Interval Initial Measurement Function : This option defines the BPA Script used to apply a function to an interval initial measurement curve on the Initial Measurement Lens zone of the Initial Measurement portal. This option can be defined multiple times for the same measuring component.

•

Manual Override IMD BO : This option identifies the initial measurement data business object to use when creating new "manual" type initial measurement data for the measuring component.

For example, for the D1-IntervalChannel measuring component business object, this option is set to D1-ManualIMDInterval, meaning that new "manual" type initial measurement data for measuring components based on the D1-IntervalChannel business object would use the D1-ManualIMDInterval business object.

•

Measuring Component Consumption Function : This option defines the BPA Script used to apply a function to the measuring component's consumption on the zones of the Measuring Component portal in the 360 Degree View. This option can be defined multiple times for the same measuring component.

•

Synchronization Add BO : This option identifies the business object to use when adding new measuring components as a result of a data synchronization request.

System Events

Measuring component business objects can make use of the following system events:

•

Find Constituent Measuring Components : This system event defines the algorithm to use to identify constituent measuring components related to an aggregator measuring component. (An aggregator’s constituent measuring components are the individual measuring components whose measurement data is aggregated when creating aggregation measurement data).

•

Periodic Estimation : This system event defines the algorithm to use when performing periodic estimation for the measuring component.

Configuration Options

This section outlines specific configuration options, such as business object options, system events, and other options used by measuring component business objects.

Business Object Options

Measuring component business objects can make use of the following business object options:

•

Estimation Initial Measurement Data BO : This option identifies the initial measurement data business object to use when creating new "estimation" type initial measurement data for the measuring component.

For example, for the D1-IntervalChannel measuring component business object, this option is set to D1-EstimationIMDInterval, meaning that new "estimation" type initial measurement data for measuring components based on the D1-IntervalChannel business object would use the D1-EstimationIMDInterval business object.

•

Interval Initial Measurement Function : This option defines the BPA Script used to apply a function to an interval initial measurement curve on the Initial Measurement Lens zone of the Initial Measurement portal. This option can be defined multiple times for the same measuring component.

•

Manual Override IMD BO : This option identifies the initial measurement data business object to use when creating new "manual" type initial measurement data for the measuring component.

For example, for the D1-IntervalChannel measuring component business object, this option is set to D1-ManualIMDInterval, meaning that new "manual" type initial measurement data for measuring components based on the D1-IntervalChannel business object would use the D1-ManualIMDInterval business object.

•

Measuring Component Consumption Function : This option defines the BPA Script used to apply a function to the measuring component's consumption on the zones of the Measuring Component portal in the 360 Degree View. This option can be defined multiple times for the same measuring component.

•

Synchronization Add BO : This option identifies the business object to use when adding new measuring components as a result of a data synchronization request.

System Events

Measuring component business objects can make use of the following system events:

•

Find Constituent Measuring Components : This system event defines the algorithm to use to identify constituent measuring components related to an aggregator measuring component. (An aggregator’s constituent measuring components are the individual measuring components whose measurement data is aggregated when creating aggregation measurement data).

•

Periodic Estimation : This system event defines the algorithm to use when performing periodic estimation for the measuring component.

Configuration Options

This section outlines specific configuration options, such as business object options, system events, and other options used by measuring component business objects.

Business Object Options

Measuring component business objects can make use of the following business object options:

•

Estimation Initial Measurement Data BO : This option identifies the initial measurement data business object to use when creating new "estimation" type initial measurement data for the measuring component.

For example, for the D1-IntervalChannel measuring component business object, this option is set to D1-EstimationIMDInterval, meaning that new "estimation" type initial measurement data for measuring components based on the D1-IntervalChannel business object would use the D1-EstimationIMDInterval business object.

•

Interval Initial Measurement Function : This option defines the BPA Script used to apply a function to an interval initial measurement curve on the Initial Measurement Lens zone of the Initial Measurement portal. This option can be defined multiple times for the same measuring component.

•

Manual Override IMD BO : This option identifies the initial measurement data business object to use when creating new "manual" type initial measurement data for the measuring component.

For example, for the D1-IntervalChannel measuring component business object, this option is set to D1-ManualIMDInterval, meaning that new "manual" type initial measurement data for measuring components based on the D1-IntervalChannel business object would use the D1-ManualIMDInterval business object.

•

Measuring Component Consumption Function : This option defines the BPA Script used to apply a function to the measuring component's consumption on the zones of the Measuring Component portal in the 360 Degree View. This option can be defined multiple times for the same measuring component.

•

Synchronization Add BO : This option identifies the business object to use when adding new measuring components as a result of a data synchronization request.

System Events

Measuring component business objects can make use of the following system events:

•

Find Constituent Measuring Components : This system event defines the algorithm to use to identify constituent measuring components related to an aggregator measuring component. (An aggregator’s constituent measuring components are the individual measuring components whose measurement data is aggregated when creating aggregation measurement data).

•

Periodic Estimation : This system event defines the algorithm to use when performing periodic estimation for the measuring component.

Example Measuring Component - D1-IntervalChannel

The table below lists the details of the D1-IntervalChannel measuring component business object.

Option

Description

Business Object

D1-IntervalChannel

Description

Interval Channel

Maintenance Object

D1-MEASRCOMP (Measuring Component)

Application Service

D1-MEASURINGCOMP (Measuring Component MO)

Instance Control

Allow New Instances

Options

•

Estimation Initial Measurement Data BO: D1-EstimationIMDInterval (Estimation IMD (Interval))

•

Manual Override IMD BO: D1-ManualIMDInterval (Manual IMD (Interval))

•

Synchronization Add BO: D1-SynchronizationAddMC (Measuring Component Synchronization Add)

•

Measuring Component Consumption Functions:

•

D2-CScIntFnc (Create Scratchpad)

•

D2-IETExc (Export to Excel)

•

D2-NewIntFnc (New IMD via XML)

•

D2-OvrIntFnc (Create/Override)

•

D2-RedValFnc (Rederive Values)

•

D2-SAsIntFnc (Save As)

•

Interval Initial Measurement Functions:

•

D2-AdjMathF (Adjust Intervals Using Math)

•

D2-AdjScalF (Adjust Intervals to Scalar Quantity)

•

D2-IIMDSAsF (Save As)

•

D2-InsIntF (Insert Intervals)

•

D2-RemIntF (Remove Intervals)

•

D2-SetCondsF (Set Conditions)

•

D2-ShiftIntF (Shift Intervals)

•

D2-SmoSpikeF (Smooth Spikes)

•

Portal Navigation Option: d1mcTabMenu (Measuring Component)

•

Display Map Service Script: D1-RtMcIcChs (Interval Channel - Retreive Details for Display)

Algorithms

•

Periodic Estimation: D1-CRIMTODO (Create Initial Measurement and To Do Entry)

•

Information: D1-SMTMCINFO (Measuring Component for Smart Devices - Information)

•

Pre-Processing: D1-DIMDCPRE (Delete Initial Measurement Data of Measuring Component.

•

Validation: D1-RELMCCVAL (Validate Consumption Reference Measuring Component)

•

Validation: D1-INTMCVAL (Check if Measuring Component’s Type is Interval)

Use the Business Object portal to view additional details concerning this business object.

Configuring Devices, Measuring Components, and Device Configurations

This section provides high-level overviews of the steps involved in configuring custom devices, device configurations, measuring component types, and measuring components. See Configuration Process Overview in Chapter One for a high-level overview of the overall configuration process.

Note : The procedures below focus on specific configuration tasks and options related to each of the objects described in this chapter, and do not address all the steps involved in creating business objects and other configuration objects. For more information about these subjects, refer to the Oracle Utilities Application Framework documentation.

Configuring Custom Devices

Configuring custom devices involves the following steps:

1.

Design the device business objects you will need to create for your implementation, including the data and processing required for each.

2.

Create the custom device-related configuration objects required for your business objects, including:

Business Object Options : Create business objects for the following business object options:

•

Install Event BO

•

Synchronization Add BO

•

Valid Command Request BO (if using Oracle Utilities Smart Grid Gateway)

3.

Create your device business objects, referencing the configuration objects created above as appropriate.

4.

Set up admin records that define the device types you will use in your implementation.

Configuring Custom Device Configurations

Configuring custom device configurations involves the following steps:

1.

Design the device configuration business objects you will need to create for your implementation, including the data and processing required for each.

2.

Create the custom device configuration-related configuration objects required for your business objects, including:

Business Object Options : Create business objects for the following business object options:

•

Synchronization Add BO

3.

Create your device configuration business objects, referencing the configuration objects created above as appropriate.

4.

Set up admin records that define the device configuration types you will use in your implementation.

Configuring Custom Measuring Component Types

Configuring custom measuring component types involves the following steps:

1.

Design the measuring component type business objects you will need to create for your implementation, including the data and processing required for each.

2.

Create the custom measuring component type-related configuration objects required for your business objects, including:

System Events : Create algorithms for the following system events:

•

Calculate Interval Consumption (for interval and scalar measuring component types)

•

Calculate Scalar Consumption (for scalar measuring component types)

Options : Create data as appropriate for the following options used when creating measuring component types:

•

Value Identifiers: Value Derivation Algorithms (based on the D1-DERIVAQTY Algorithm Type)

•

VEE Groups

•

Profile Factors

•

Scratchpad Measuring Component Types

•

Display Properties:

•

Event Bar Profiles: Values for the D1-360EventBarProfile extendable lookup

•

Final Values Overlay Profiles: Values for the D1-FinalValuesOverlayProfile extendable lookup.

3.

Create your measuring component type business objects, referencing the configuration objects created above as appropriate.

4.

Set up admin records that define the measuring component types you will use in your implementation.

Configuring Custom Measuring Components

Configuring custom measuring components involves the following steps:

1.

Design the measuring component business objects you will need to create for your implementation, including the data and processing required for each.

2.

Create the custom measuring component-related configuration objects required for your business objects, including:

Business Object Options : Create business objects and algorithms for the following business object options:

•

Estimation Initial Measurement Data BO

•

Interval Initial Measurement Function

•

Manual Override IMD BO

•

Measuring Component Consumption Function

•

Synchronization Add BO

3.

Create your measuring component business objects, referencing the configuration objects created above as appropriate.

Service Points and Device Installation

This chapter provides descriptions of entities related to installation of meters, including service points, contacts, install events, activities, and other entities. This chapter includes:

•

Understanding Service Points and Device Installation

•

Service Points In Detail

•

Contacts In Detail

•

Install Events In Detail

•

Service Providers In Detail

•

Processing Methods In Detail

•

Configuring Service Point and Device Installation Objects

Note : References to objects and options pre-fixed with "D2" are available only with Oracle Utilities Meter Data Management, and included for illustrative purposes only.

Understanding Service Points and Device Installation

This section provides an overview of entities related to the installation of devices (service points, contacts, install events, service providers, and others) how they are used in the Service and Measurement Data Foundation and related products, including Oracle Utilities Meter Data Management and Oracle Utilities Smart Grid Gateway.

Service Points

Service points are physical locations at which a company supplies service. Devices are installed at service points. The relationship between individual service points and devices can change over time. For example, at any point in time:

•

A service point may have a single device installed (or no device may be installed)

•

A device may be installed at a single service point (or it may not be installed at a service points)

Over time:

•

Different devices may be installed at a service point

•

A device may be installed at different service points

An Aside: No Premise Object Exists

Oracle Utilities Meter Data Management (and other related meter data products) is not the system of record for premises or service points. The customer information system (or some other system) is considered the system of record for this type of information. In order to minimize the amount of data that needs to be synchronized, premise-oriented attributes used by meter data products are held on service points. This is an important distinction to keep in mind when creating custom service points for your implementation.

Contacts

Contacts are individuals or business entities with which a company has contact. Service points can have associated contacts which define the individual or business entity that uses the service (electricity, gas, water, etc.) delivered at the service point. Note that while contacts are optional for service points, usage subscriptions must reference contacts.

Note : The base-package name search on the 360° Search looks for usage subscription-related contacts. Use the Service Point Query portal to find a service point using a service point-related contact.

Installation Events

Whenever a device is installed at a service point, an installation event is created. Installation events capture the history of the devices that have been installed at a service point. This allows consumption for a service point to be calculated over time. In technical terms, installation events (or install events) link a specific device configuration to a service point.

There are specific install event business objects for different types of devices, including smart meters, manual meters, and communication components.

While a device is installed at a service point, it may be turned off (and back on again). The installation event that records the original installation date and time also records the dates and times when the device has been turned on and off. When a device is removed, the original installation event is updated with the removal date and time.

Service Providers

Service provider are external entities that serve various roles relative to the application. These can include head-end systems, billing systems to which the application sends bill determinant data, market participants in a deregulated environment, outage management systems that receive meter event data from the application, or other parties that require or provide information to the system.

Service providers can have one or more associated processing methods that define the format or means by which a service provider receives data from the application, such as bill determinants, interval data, or meter events. Processing methods are also used to define how to create information internal to the application such as initial measurement data and usage transactions. Processing methods can also be used to define the information an external system wishes to subscribe to receive from our application.

Service Providers as Head-End Systems

Head-end systems are systems that collect measurement data and meter events for eventual submission to the application. Many devices can communicate to the application through a single head-end system, but a utility may have numerous head-end systems through which they communicate with devices.

As noted above, head-end systems are defined as service providers. Head-end systems utilize a processing method that specifies the type of initial measurement data to create for devices (and their related measuring components) based on measuring component type.

Service Providers in Deregulated Markets

Some utilities operate in deregulated markets. In implementations in deregulated markets, the system can send information to and receive information from a variety of market entities. These entities are defined as service providers.

For example, a service point’s distribution company and/or energy supply company may subscribe to its consumption, or a service point’s meter service provider may send requests to ping the meter that's installed at the service point to verify connectivity between the meter and its head-end system.

Different Relationship Types In Different Markets

Each market can define different relationship types between its service providers. A single instance of Oracle Utilities Meter Data Management or Oracle Utilities Smart Grid Gateway may have service points in different markets where each market has different relationship types and service providers. For example:

•

In a regulated market the distribution company is the de facto energy supplier and meter service provider.

•

Another market might have two relationship types and a single service provider for each relationship:

1.There is a single energy supply company for the entire market

2.There is a single meter service provider for the entire market

•

Yet a another market might have two relationship types (energy supply and meter service). In this market, there might be multiple service providers for each relationship type. Each service point can choose any of the relationship type's service providers. If a service point does not declare a specific service provider for a given relationship type, the relationship type's "fallback" service provider is assumed.

Service Providers

Service provider are external entities that serve various roles relative to the application. These can include head-end systems, billing systems to which the application sends bill determinant data, market participants in a deregulated environment, outage management systems that receive meter event data from the application, or other parties that require or provide information to the system.

Service providers can have one or more associated processing methods that define the format or means by which a service provider receives data from the application, such as bill determinants, interval data, or meter events. Processing methods are also used to define how to create information internal to the application such as initial measurement data and usage transactions. Processing methods can also be used to define the information an external system wishes to subscribe to receive from our application.

Service Providers as Head-End Systems

Head-end systems are systems that collect measurement data and meter events for eventual submission to the application. Many devices can communicate to the application through a single head-end system, but a utility may have numerous head-end systems through which they communicate with devices.

As noted above, head-end systems are defined as service providers. Head-end systems utilize a processing method that specifies the type of initial measurement data to create for devices (and their related measuring components) based on measuring component type.

Service Providers in Deregulated Markets

Some utilities operate in deregulated markets. In implementations in deregulated markets, the system can send information to and receive information from a variety of market entities. These entities are defined as service providers.

For example, a service point’s distribution company and/or energy supply company may subscribe to its consumption, or a service point’s meter service provider may send requests to ping the meter that's installed at the service point to verify connectivity between the meter and its head-end system.

Different Relationship Types In Different Markets

Each market can define different relationship types between its service providers. A single instance of Oracle Utilities Meter Data Management or Oracle Utilities Smart Grid Gateway may have service points in different markets where each market has different relationship types and service providers. For example:

•

In a regulated market the distribution company is the de facto energy supplier and meter service provider.

•

Another market might have two relationship types and a single service provider for each relationship:

1.There is a single energy supply company for the entire market

2.There is a single meter service provider for the entire market

•

Yet a another market might have two relationship types (energy supply and meter service). In this market, there might be multiple service providers for each relationship type. Each service point can choose any of the relationship type's service providers. If a service point does not declare a specific service provider for a given relationship type, the relationship type's "fallback" service provider is assumed.

Service Providers

Service provider are external entities that serve various roles relative to the application. These can include head-end systems, billing systems to which the application sends bill determinant data, market participants in a deregulated environment, outage management systems that receive meter event data from the application, or other parties that require or provide information to the system.

Service providers can have one or more associated processing methods that define the format or means by which a service provider receives data from the application, such as bill determinants, interval data, or meter events. Processing methods are also used to define how to create information internal to the application such as initial measurement data and usage transactions. Processing methods can also be used to define the information an external system wishes to subscribe to receive from our application.

Service Providers as Head-End Systems

Head-end systems are systems that collect measurement data and meter events for eventual submission to the application. Many devices can communicate to the application through a single head-end system, but a utility may have numerous head-end systems through which they communicate with devices.

As noted above, head-end systems are defined as service providers. Head-end systems utilize a processing method that specifies the type of initial measurement data to create for devices (and their related measuring components) based on measuring component type.

Service Providers in Deregulated Markets

Some utilities operate in deregulated markets. In implementations in deregulated markets, the system can send information to and receive information from a variety of market entities. These entities are defined as service providers.

For example, a service point’s distribution company and/or energy supply company may subscribe to its consumption, or a service point’s meter service provider may send requests to ping the meter that's installed at the service point to verify connectivity between the meter and its head-end system.

Different Relationship Types In Different Markets

Each market can define different relationship types between its service providers. A single instance of Oracle Utilities Meter Data Management or Oracle Utilities Smart Grid Gateway may have service points in different markets where each market has different relationship types and service providers. For example:

•

In a regulated market the distribution company is the de facto energy supplier and meter service provider.

•

Another market might have two relationship types and a single service provider for each relationship:

1.There is a single energy supply company for the entire market

2.There is a single meter service provider for the entire market

•

Yet a another market might have two relationship types (energy supply and meter service). In this market, there might be multiple service providers for each relationship type. Each service point can choose any of the relationship type's service providers. If a service point does not declare a specific service provider for a given relationship type, the relationship type's "fallback" service provider is assumed.

Measurement Cycles

Measurement cycles define the schedule for manual meter reading of devices at service points. More specifically:

•

A measurement cycle defines WHEN the service point is visited

•

A route within a cycle defines a group of service points in a cycle that are visited by a meter reader

•

A sequence within a route defines the physical position of the service point within a route

•

A schedule specifies the dates on which service points are visited.

Manually read service point reference a measurement cycle, route and sequence within the route. A batch process creates SP/Measurement Cycle Schedule Routes for each service point, which link the dates on a measurement cycle schedule to a measurement cycle route defined for the service point. These define the specific date on which a meter reader will visit service points associated with a specific measurement cycle route, and the sequence in which the service points on that route are visited.

The Route Management portal allows users to manually manage the sequence of service points within a route, including renumbering the sequence of a user-selected set of service points and transferring one or more service to a different measurement cycle route.

Measurement Cycles can also be used to periodically push bill determinants to subscribing systems. See Measurement Cycle And Creating Bill Determinants below for more information.

Measurement Cycle Batch Processing

Measurement cycle processing is managed by the following three batch processes:

•

Create Pending Measurement Cycle Schedule Routes (D1-CMCS)

This batch process creates Schedule Routes for Measurement Cycle Schedules whose schedule selection date is on or before the batch business date. This process is used if routes have the same schedule each month, quarter, etc. This process simply copies the routes from the Measurement Cycle to the Measurement Cycle Schedule on/after the scheduled selection date.

•

Create Pending SP / Measurement Cycle Schedule Route Records (D1-CSPSR)

This batch process creates a "SP/Measurement Cycle Schedule Route" transaction for every service point in the Measurement Cycle Schedule Route that is ready for processing.

•

Process Pending SP / Measurement Cycle Schedule Route Records (D1-PSPSR)

This batch process transitions the Pending "SP/Measurement Cycle Schedule Route" transactions to their Complete state. Custom algorithms can be configured to do any additional necessary work, such as creating a "Meter Read Download" activity. This custom algorithm would be configured as an Enter algorithm on the "Complete" state of the SP/Measurement Cycle Schedule Route business object.

Measurement Cycle And Creating Bill Determinants

The system can be configured to periodically push bill determinants to subscribing systems. In this case, measurement cycles can be configured to define when to create usage transactions for usage subscriptions associated to service points in the cycle. In this case, even service points whose meters are read automatically may reference measurement cycles.

Creating bill determinants (by creating a usage transaction) is performed by an algorithm on the "Complete" state of the SP/Measurement Cycle Schedule Route business object (similar to creating activities as described above).

When the Pending SP/Measurement Cycle Schedule Route records are processed by the "Process Pending SP / Measurement Cycle Schedule Route Records" process (D1-PSPSR), rather than create a handheld download activity, the algorithm can create a usage transaction (usage transactions are transactions that cause bill determinants to be calculated for the service point’s usage subscription(s)).

If the implementation needs to both manually read the meter and push bill determinants, both algorithms would be plugged in on the SP/Measurement Cycle Schedule Route business object.

Measurement Cycles

Measurement cycles define the schedule for manual meter reading of devices at service points. More specifically:

•

A measurement cycle defines WHEN the service point is visited

•

A route within a cycle defines a group of service points in a cycle that are visited by a meter reader

•

A sequence within a route defines the physical position of the service point within a route

•

A schedule specifies the dates on which service points are visited.

Manually read service point reference a measurement cycle, route and sequence within the route. A batch process creates SP/Measurement Cycle Schedule Routes for each service point, which link the dates on a measurement cycle schedule to a measurement cycle route defined for the service point. These define the specific date on which a meter reader will visit service points associated with a specific measurement cycle route, and the sequence in which the service points on that route are visited.

The Route Management portal allows users to manually manage the sequence of service points within a route, including renumbering the sequence of a user-selected set of service points and transferring one or more service to a different measurement cycle route.

Measurement Cycles can also be used to periodically push bill determinants to subscribing systems. See Measurement Cycle And Creating Bill Determinants below for more information.

Measurement Cycle Batch Processing

Measurement cycle processing is managed by the following three batch processes:

•

Create Pending Measurement Cycle Schedule Routes (D1-CMCS)

This batch process creates Schedule Routes for Measurement Cycle Schedules whose schedule selection date is on or before the batch business date. This process is used if routes have the same schedule each month, quarter, etc. This process simply copies the routes from the Measurement Cycle to the Measurement Cycle Schedule on/after the scheduled selection date.

•

Create Pending SP / Measurement Cycle Schedule Route Records (D1-CSPSR)

This batch process creates a "SP/Measurement Cycle Schedule Route" transaction for every service point in the Measurement Cycle Schedule Route that is ready for processing.

•

Process Pending SP / Measurement Cycle Schedule Route Records (D1-PSPSR)

This batch process transitions the Pending "SP/Measurement Cycle Schedule Route" transactions to their Complete state. Custom algorithms can be configured to do any additional necessary work, such as creating a "Meter Read Download" activity. This custom algorithm would be configured as an Enter algorithm on the "Complete" state of the SP/Measurement Cycle Schedule Route business object.

Measurement Cycle And Creating Bill Determinants

The system can be configured to periodically push bill determinants to subscribing systems. In this case, measurement cycles can be configured to define when to create usage transactions for usage subscriptions associated to service points in the cycle. In this case, even service points whose meters are read automatically may reference measurement cycles.

Creating bill determinants (by creating a usage transaction) is performed by an algorithm on the "Complete" state of the SP/Measurement Cycle Schedule Route business object (similar to creating activities as described above).

When the Pending SP/Measurement Cycle Schedule Route records are processed by the "Process Pending SP / Measurement Cycle Schedule Route Records" process (D1-PSPSR), rather than create a handheld download activity, the algorithm can create a usage transaction (usage transactions are transactions that cause bill determinants to be calculated for the service point’s usage subscription(s)).

If the implementation needs to both manually read the meter and push bill determinants, both algorithms would be plugged in on the SP/Measurement Cycle Schedule Route business object.

Measurement Cycles

Measurement cycles define the schedule for manual meter reading of devices at service points. More specifically:

•

A measurement cycle defines WHEN the service point is visited

•

A route within a cycle defines a group of service points in a cycle that are visited by a meter reader

•

A sequence within a route defines the physical position of the service point within a route

•

A schedule specifies the dates on which service points are visited.

Manually read service point reference a measurement cycle, route and sequence within the route. A batch process creates SP/Measurement Cycle Schedule Routes for each service point, which link the dates on a measurement cycle schedule to a measurement cycle route defined for the service point. These define the specific date on which a meter reader will visit service points associated with a specific measurement cycle route, and the sequence in which the service points on that route are visited.

The Route Management portal allows users to manually manage the sequence of service points within a route, including renumbering the sequence of a user-selected set of service points and transferring one or more service to a different measurement cycle route.

Measurement Cycles can also be used to periodically push bill determinants to subscribing systems. See Measurement Cycle And Creating Bill Determinants below for more information.

Measurement Cycle Batch Processing

Measurement cycle processing is managed by the following three batch processes:

•

Create Pending Measurement Cycle Schedule Routes (D1-CMCS)

This batch process creates Schedule Routes for Measurement Cycle Schedules whose schedule selection date is on or before the batch business date. This process is used if routes have the same schedule each month, quarter, etc. This process simply copies the routes from the Measurement Cycle to the Measurement Cycle Schedule on/after the scheduled selection date.

•

Create Pending SP / Measurement Cycle Schedule Route Records (D1-CSPSR)

This batch process creates a "SP/Measurement Cycle Schedule Route" transaction for every service point in the Measurement Cycle Schedule Route that is ready for processing.

•

Process Pending SP / Measurement Cycle Schedule Route Records (D1-PSPSR)

This batch process transitions the Pending "SP/Measurement Cycle Schedule Route" transactions to their Complete state. Custom algorithms can be configured to do any additional necessary work, such as creating a "Meter Read Download" activity. This custom algorithm would be configured as an Enter algorithm on the "Complete" state of the SP/Measurement Cycle Schedule Route business object.

Measurement Cycle And Creating Bill Determinants

The system can be configured to periodically push bill determinants to subscribing systems. In this case, measurement cycles can be configured to define when to create usage transactions for usage subscriptions associated to service points in the cycle. In this case, even service points whose meters are read automatically may reference measurement cycles.

Creating bill determinants (by creating a usage transaction) is performed by an algorithm on the "Complete" state of the SP/Measurement Cycle Schedule Route business object (similar to creating activities as described above).

When the Pending SP/Measurement Cycle Schedule Route records are processed by the "Process Pending SP / Measurement Cycle Schedule Route Records" process (D1-PSPSR), rather than create a handheld download activity, the algorithm can create a usage transaction (usage transactions are transactions that cause bill determinants to be calculated for the service point’s usage subscription(s)).

If the implementation needs to both manually read the meter and push bill determinants, both algorithms would be plugged in on the SP/Measurement Cycle Schedule Route business object.

Service Points In Detail

This section provides details concerning the service point objects supplied as part of the base package. This information illustrates how the base package objects were designed, and can serve as the basis for any custom service point objects you create as part of your implementation. This section includes:

•

A description of the D1-SP maintenance object

•

Lists of the base package service point business objects, including "lite" business objects

•

Details concerning service point-specific configuration options

•

A sample service point business object (D1-ServicePoint)

Maintenance Object - D1-SP

Service point business objects use the D1-SP maintenance object. The table below outlines some of the details of this maintenance object.

Option/Field

Description

Maintenance Object

D1-SP

Description

Service Point

Service Name

D1-SP (Service Point Maintenance)

Tables

•

D1_SP (Service Point) - Primary

•

D1_SP_REL (Service Point Relationship) - Child

•

D1_SP_CHAR (Service Point Characteristics) - Child

•

D1_SP_CONTACT (Service Point Contact) - Child

•

D1_SP_IDENTIFIER (Service Point Identifier) - Child

•

D1_SP_LOG (Service Point Log) - Child

•

D1_SP_LOG_PARM (Service Point Log Parameter) - Child

•

D1_SP_MKT_PARTICIPANT (Service Point Market Participant) - Child

Use the Maintenance Object portal and the Application Viewer to view more details about this maintenance object.

Service and Measurement Data Foundation Base Package Service Point Business Objects

The Service and Measurement Data Foundation base package includes the following service point business objects:

Business Object Name

Description

D1-ServicePoint

Service Point

Instances of this business object represent individual service points defined in the system.

The Service and Measurement Data Foundation base package includes the following "lite" service point business objects:

Business Object Name

Description

D1-SPForCEUpd

SP For Completion Event Update

D1-SPLite

Service Point Lite

D1-ServicePointODMBORead

Service Point ODM BO to Read

D1-ServicePointParentLITE

Service Point Parent LITE

The Service and Measurement Data Foundation base package includes the following additional service point business objects:

Business Object Name

Description

D1-SynchronizationAddSP

Service Point Synchronization Add (used when adding a new service point as a result of a data synchronization request)

Configuration Options

This section outlines specific configuration options, such as business object options, system events, and other options used by service point business objects.

Business Object Options

Service point business objects can make use of the following business object options:

•

Synchronization Add BO : This option identifies the business object to use when adding new service points as a result of a data synchronization request.

System Events

Service point business objects can make use of the following system events:

•

Service Point Snapshot : This system event defines the algorithm used to create a snapshot of the service point for use with Oracle Utilities Business Intelligence. The Algorithm Entity for available algorithms is "SP (BO) - Snapshot."

•

Usage Snapshot : This system event defines the algorithm used to create a usage snapshot of the service point for use with Oracle Utilities Business Intelligence. The Algorithm Entity for available algorithms is "SP (BO) - Usage Snapshot."

•

Unreported Usage Analysis Snapshot : This system event defines the algorithm used to create a snapshot of the service point’s consumption since the last usage transaction for use with Oracle Utilities Business Intelligence. The Algorithm Entity for available algorithms is "SP (BO) - Unreported Usage Analysis Snapshot."

•

SP VEE Exception Snapshot : This system event defines the algorithm used to create a snapshot of VEE exceptions for the service point for use with Oracle Utilities Business Intelligence. The Algorithm Entity for available algorithms is "SP (BO) - VEE Exception Snapshot."

Configuration Options

This section outlines specific configuration options, such as business object options, system events, and other options used by service point business objects.

Business Object Options

Service point business objects can make use of the following business object options:

•

Synchronization Add BO : This option identifies the business object to use when adding new service points as a result of a data synchronization request.

System Events

Service point business objects can make use of the following system events:

•

Service Point Snapshot : This system event defines the algorithm used to create a snapshot of the service point for use with Oracle Utilities Business Intelligence. The Algorithm Entity for available algorithms is "SP (BO) - Snapshot."

•

Usage Snapshot : This system event defines the algorithm used to create a usage snapshot of the service point for use with Oracle Utilities Business Intelligence. The Algorithm Entity for available algorithms is "SP (BO) - Usage Snapshot."

•

Unreported Usage Analysis Snapshot : This system event defines the algorithm used to create a snapshot of the service point’s consumption since the last usage transaction for use with Oracle Utilities Business Intelligence. The Algorithm Entity for available algorithms is "SP (BO) - Unreported Usage Analysis Snapshot."

•

SP VEE Exception Snapshot : This system event defines the algorithm used to create a snapshot of VEE exceptions for the service point for use with Oracle Utilities Business Intelligence. The Algorithm Entity for available algorithms is "SP (BO) - VEE Exception Snapshot."

Configuration Options

This section outlines specific configuration options, such as business object options, system events, and other options used by service point business objects.

Business Object Options

Service point business objects can make use of the following business object options:

•

Synchronization Add BO : This option identifies the business object to use when adding new service points as a result of a data synchronization request.

System Events

Service point business objects can make use of the following system events:

•

Service Point Snapshot : This system event defines the algorithm used to create a snapshot of the service point for use with Oracle Utilities Business Intelligence. The Algorithm Entity for available algorithms is "SP (BO) - Snapshot."

•

Usage Snapshot : This system event defines the algorithm used to create a usage snapshot of the service point for use with Oracle Utilities Business Intelligence. The Algorithm Entity for available algorithms is "SP (BO) - Usage Snapshot."

•

Unreported Usage Analysis Snapshot : This system event defines the algorithm used to create a snapshot of the service point’s consumption since the last usage transaction for use with Oracle Utilities Business Intelligence. The Algorithm Entity for available algorithms is "SP (BO) - Unreported Usage Analysis Snapshot."

•

SP VEE Exception Snapshot : This system event defines the algorithm used to create a snapshot of VEE exceptions for the service point for use with Oracle Utilities Business Intelligence. The Algorithm Entity for available algorithms is "SP (BO) - VEE Exception Snapshot."

Example Service Point - D1-ServicePoint

The table below lists the details of the D1-ServicePoint service point business object.

Option

Description

Business Object

D1-ServicePoint

Description

Service Point

Maintenance Object

D1-SP (Service Point)

Application Service

D1-SPBOAS (Service Point BO)

Instance Control

Allow New Instances

Options

•

Synchronization Add BO: D1-SynchronizationAddSP (Service Point Synchronization Add)

•

Display UI Map: D1-SPDisplay (Service Point - Display)

•

Portal Navigation Option: d1spTabMenu (Service Point)

•

Pre-Processing Service Script: D1-SPMtnPre (Service Point Maintenance Pre-Processing)

•

Display Map Service Script: D1-SPRetDts (Service Point - Retreive Details for Display)

•

Maintenance UI Map: D1-SPMaint (Service Point - Maintenance)

Algorithms

•

Information: D1-SPINFO (Service Point Information)

•

Pre-Processing: D1-DEFTIMZON (Default Time Zone Value based on Installation Option)

•

Validation: D1-SPADDRVAL (Validate Service Point’s Address Information)

•

Validation: D1-MSCYCVAL (Validate Service Point’s Measurement Cycle Information

•

Validation: D1-VALTIMZON (Validate BO Time Zone Against Installation Option)

Lifecycle

•

Active (Initial)

•

Inactive (Final)

Use the Business Object portal to view additional details concerning this business object.

Contacts In Detail

This section provides details concerning the contact objects supplied as part of the base package. This information illustrates how the base package objects were designed, and can serve as the basis for any custom contact objects you create as part of your implementation. This section includes:

•

A description of the D1-CONTACT maintenance object

•

Lists of the base package contact business objects

•

A sample contact business object (D1-Business)

Maintenance Object - D1-CONTACT

Contact business objects use the D1-CONTACT maintenance object. The table below outlines some of the details of this maintenance object.

Option/Field

Description

Maintenance Object

D1-CONTACT

Description

Contact

Service Name

D1-CONTACT (Contact Maintenance)

Tables

•

D1_CONTACT (Contact) - Primary

•

D1_CONTACT_CHAR (Contact Characteristics) - Child

•

D1_CONTACT_EMAIL (Contact Email) - Child

•

D1_CONTACT_IDENTIFIER (Contact Identifier) - Child

•

D1_CONTACT_NAME (Contact Name) - Child

•

D1_CONTACT_PHONE (Contact Phone) - Child

Use the Maintenance Object portal and the Application Viewer to view more details about this maintenance object.

Service and Measurement Data Foundation Base Package Contact Business Objects

The Service and Measurement Data Foundation base package includes the following contact business objects:

Business Object Name

Description

D1-Business

Business

Instances of this business object represent individual business contacts defined in the system.

D1-Person

Person

Instances of this business object represent individual person contacts defined in the system.

The Service and Measurement Data Foundation base package includes the following "lite" contact business objects:

Business Object Name

Description

D1-ContactLITE

Usage Transaction To Do Contact LITE

D1-ContactODMBORead

Contact ODM BO to Read

The Service and Measurement Data Foundation base package includes the following additional contact business objects:

Business Object Name

Description

D1-SynchronizationAddContact

Contact Synchronization Add (used when adding a new contact as a result of a data synchronization request)

Example Contact - D1-Business

The table below lists the details of the D1-Business contact business object.

Option

Description

Business Object

D1-Business

Description

Business

Maintenance Object

D1-CONTACT (Contact)

Application Service

D1-CONTACT (Contact MO)

Instance Control

Allow New Instances

Options

•

Synchronization Add BO: D1-SynchronizationAddContact (Contact Synchronization Add)

•

Display UI Map: D1-BusinessDisplay (Business - Display)

•

Portal Navigation Option: d1contctTabMenu (Contact)

•

Display Map Service Script: D1-RtBusDtl (Contact - Retreive Details for Display)

•

Maintenance UI Map: D1-BusinessMaint (Business - Maintenance)

Algorithms

•

Information: D1-BUS-INFO (Business Contact - Information)

Use the Business Object portal to view additional details concerning this business object.

Install Events In Detail

This section provides details concerning the install event objects supplied as part of the base package. This information illustrates how the base package objects were designed, and can serve as the basis for any custom install event objects you create as part of your implementation. This section includes:

•

A description of the D1-INSTLEVT maintenance object

•

Lists of the base package install event business objects, including "lite" business objects

•

A sample install event business object (D1-SmartMeterInstallEvent)

Maintenance Object - D1-INSTLEVT

Install event business objects use the D1-INSTLEVT maintenance object. The table below outlines some of the details of this maintenance object.

Option/Field

Description

Maintenance Object

D1-INSTLEVT

Description

Install Event

Service Name

D1-INSTLEVT (Install Event Maintenance)

Tables

•

D1_INSTLEVT (Install Event) - Primary

•

D1_INSTLEVT_CHAR (Install Event Characteristics) - Child

•

D1_INSTLEVT_LOG (Install Event Log) - Child

•

D1_INSTLEVT_LOG_PARM (Install Event Log Parameter) - Child

•

D1_ON_OFF_HIST (On/Off History) - Child

Use the Maintenance Object portal and the Application Viewer to view more details about this maintenance object.

Service and Measurement Data Foundation Base Package Install Event Business Objects

The Service and Measurement Data Foundation base package includes the following install event business objects:

Business Object Name

Description

D1-CommComponentInstallEvent

Communication Component Install Event

Instances of this business object represent individual communication component installation events defined in the system.

D1-ManualMeterInstallEvent

Manual Meter Installation Event

Instances of this business object represent individual manual meter installation events defined in the system.

D1-SmartMeterInstallEvent

Smart Meter Installation Event

Instances of this business object represent individual smart meter installation events defined in the system.

The Service and Measurement Data Foundation base package includes the following "lite" install event business objects:

Business Object Name

Description

D1-CommCompInstallEventLITE

Communication Component Install Event LITE

D1-InstallEventBORead

ODM Install Event BO to Read

D1-InstallEventLite

Install Event Lite

D1-InstallEventMainLite

Install Event Main LITE

D1-InstallEventParentLITE

Install Event Parent LITE

D1-SmartMeterInstallEventLite

Smart Meter Install Event LITE

The Service and Measurement Data Foundation base package includes the following additional install event business objects:

Business Object Name

Description

D1-SynchronizationAddIE

Install Event Synchronization Add (used when adding a new installation event as a result of a data synchronization request)

Example Install Event - D1-SmartMeterInstallEvent

The table below lists the details of the D1-SmartMeterInstallEvent install event business object.

Option

Description

Business Object

D1-SmartMeterInstallEvent

Description

Smart Meter Installation Event

Maintenance Object

D1-INSTLEVT (Install Event)

Application Service

D1-SMTMTRINSEVTBOAS (Smart Event Installation Event BO)

Instance Control

Allow New Instances

Options

•

Synchronization Add BO: D1-SynchronizationAddIE (Install Event Synchronization Add)

•

Display UI Map: D1-SmartMeterInstallEventDisplay (Smart Meter Install Event - Display)

•

Portal Navigation Option: d1inevtmTabMenu (Install Event)

•

Display Map Service Script: D1-SmtIERtDt (Smart Meter Install Event - Retreive Details for Display)

•

Maintenance UI Map: D1-SmartMeterInstallEventMaint (Smart Meter Install Event - Maintenance)

Algorithms

•

Information: D1-INEVTINFO (Install Event Information)

•

Pre-Processing: D1-DFLTINSTC (Default the Install Event’s Installation Constant)

•

Pre-Processing: D1-POPARMSTS (Default the Arming Status)

•

Validation: D1-DEVCFGVAL (Validate the Device Configuration)

•

Validation: D1-ONHISTVAL (Validate the On/Off History based on the Previous Install Event)

•

Validation: D1-CHKHISEVT (Validate the On/Off History based on the Install Event’s Status)

•

Validation: D1-CKIFOVLEX (Validate Overlapping Install Events)

•

Validation: D1-VALIERMDT (Validate Removal Information)

Lifecycle

•

Pending (Initial)

•

Connected/Pre-Commissioned (Interim)

•

Pre-Connected/Commissioned (Interim)

•

Connected/Commissioned (Interim)

•

Connected/Decommissioned (Interim)

•

Disconnected/Commissioned (Interim)

•

Disconnected/Decommissioned (Interim)

•

Remove (Final)

Use the Business Object portal to view additional details concerning this business object.

Service Providers In Detail

This section provides details concerning the service provider objects supplied as part of the base package. This information illustrates how the base package objects were designed, and can serve as the basis for any custom service provider objects you create as part of your implementation. This section includes:

•

A description of the D1-SVCPROVDR maintenance object

•

Lists of the base package service provider business objects, including "lite" business objects

•

Details concerning service provider-specific configuration options

•

A sample service provider business object (D1-HeadEndSystem)

Maintenance Object - D1-SVCPROVDR

Service provider business objects use the D1-SVCPROVDR maintenance object. The table below outlines some of the details of this maintenance object.

Option/Field

Description

Maintenance Object

D1-SVCPROVDR

Description

Service Provider

Service Name

D1-SVCPROVDR (Service Provider Maintenance)

Tables

•

D1_SPR (Service Provider) - Primary

•

D1_SPR_CHAR (Service Provider Characteristics) - Child

•

D1_SPR_L (Service Provider Language) - Child

Use the Maintenance Object portal and the Application Viewer to view more details about this maintenance object.

Service and Measurement Data Foundation Base Package Service Provider Business Objects

The Service and Measurement Data Foundation base package includes the following service provider business objects:

Business Object Name

Description

D1-ExternalApplication

External Application

Instances of this business object represent individual external applications defined in the system.

D1-HeadEndSystem

Head-End System

Instances of this business object represent individual head-end systems defined in the system.

D1-MarketParticipant

Market Participant

Instances of this business object represent individual market participants defined in the system.

D1-ServiceProvider

Service Provider (generic service provider business object used as a parent business object for all other service provider business objects)

The Service and Measurement Data Foundation base package includes the following "lite" service provider business objects:

Business Object Name

Description

D1-MarketParticipantLite

Market Participant Lite

D1-MarketParticipantParentLite

Market Participant Parent Lite

The Service and Measurement Data Foundation base package includes the following additional service provider business objects:

Business Object Name

Description

D1-ServiceProviderBundlingAdBO

Bundling Add BO for Service Provider

D1-ServiceProviderPhysicalBO

Physical BO for Service Provider

Configuration Options

This section outlines specific configuration options, such as business object options, system events, and other options used by service provider business objects.

Business Object Options

Service provider business objects can make use of the following business object options:

•

Service Provider Type : This option defines the type of service provider. Valid values are defined as values for the SPR_TYPE_FLG lookup field. The base package includes the following options:

Lookup FIeld Value

Description

D1EA

Edge Application

D1HE

Head-End System

D1MP

Market Participant

Configuration Options

This section outlines specific configuration options, such as business object options, system events, and other options used by service provider business objects.

Business Object Options

Service provider business objects can make use of the following business object options:

•

Service Provider Type : This option defines the type of service provider. Valid values are defined as values for the SPR_TYPE_FLG lookup field. The base package includes the following options:

Lookup FIeld Value

Description

D1EA

Edge Application

D1HE

Head-End System

D1MP

Market Participant

Example Service Provider - D1-HeadEndSystem

The table below lists the details of the D1-HeadEndSystem service provider business object.

Option

Description

Business Object

D1-HeadEndSystem

Description

Head-End System

Maintenance Object

D1-SVCPROVDR (Service Provider)

Parent Business Object

D1-ServiceProvider

Application Service

D1-SVCPROVIDER (Service Provider MO)

Instance Control

Allow New Instances

Options

•

Service Provider Type: D1HE (Head-End)

•

Display UI Map: D1-HeadEndSystemDisplay (Head-End System - Display)

•

Portal Navigation Option: d1svcproTabMenu (Service Provider)

•

Maintenance UI Map: D1-HeadEndSystemMaint (Head-End System - Maintenance)

Use the Business Object portal to view additional details concerning this business object.

Processing Methods In Detail

This section provides details concerning the processing method objects supplied as part of the base package. This information illustrates how the base package objects were designed, and can serve as the basis for any custom processing method objects you create as part of your implementation. This section includes:

•

A description of the D1-PROCMETHD maintenance object

•

Lists of the base package processing method business objects, including "lite" business objects

•

Details concerning processing method-specific configuration options

•

A sample service processing method object (D1-HowToCreateMCInformation)

Maintenance Object - D1-PROCMETHD

Processing method business objects use the D1-PROCMETHD maintenance object. The table below outlines some of the details of this maintenance object.

Option/Field

Description

Maintenance Object

D1-PROCMETHD

Description

Processing Method

Service Name

D1-PROCMETHOD (Processing Method Maintenance)

Tables

•

D1_PROC_MTHD (Processing Method) - Primary

•

D1_PROC_MTHD_CHAR (Processing Method Characteristics) - Child

•

D1_PROC_MTHD_L (Processing Method Language) - Child

Use the Maintenance Object portal and the Application Viewer to view more details about this maintenance object.

Service and Measurement Data Foundation Base Package Business Objects

The Service and Measurement Data Foundation base package includes the following processing method business objects:

Business Object Name

Description

D1-AbstractProcessingMethod

Generic Processing Method (generic processing method business object used as a parent business object for all other processing method business objects)

D1-HowToCreateActivityOBComm

How to Create Outbound Communication / Send OB Message (used to determine the specific type of outbound communication/message to send)

D1-HowToCreateMCInformation

How To Create MC Related Information (used to define how measuring component-related information is created for the service provider, including initial measurement data)

D1-HowToProcDvceEvtsInformation

How to Process Device Event Related Information (used to send device events to a service provider)

D1-HowToProcessDeviceInfo

How to Process Device Related Information (used to define data translations for head-end systems, including how UOM codes are mapped for devices of the head-end system, how device events are mapped, how time zones are translated, etc.)

D1-HowToSendActInformation

How to Send Activity Related Informatoin (used to define how activity-related information is sent to the service provider)

D1-HowToSendActivityResponse

How to Send Activity Related Outbound Messages (used to define the outbound message type sent to a service provider in response to an activity)

The Service and Measurement Data Foundation base package includes the following additional processing method business objects:

Business Object Name

Description

D1-ProcessingMethodBundlingABO

Bundling Add BO for Processing Method

D1-ProcessingMethodPhysicalBO

Physical BO for Processing Method

Configuration Options

This section outlines specific types of BO Options and System Events used by service provider business objects.

Business Object Options

Service provider business objects can make use of the following business object options:

•

Applicable Processing Role : This option defines the processing role for the processing method. Valid values are defined as values for the PROC_ROLE_FLG lookup field. The base package includes the following options:

Lookup FIeld Value

Description

D1AM

Obtain AMI Device Identifier

D1BR

Bulk Response

D1DA

Activity Notification

D1DC

Device Commission

D1DD

Device Decommission

D1DM

Device Event Mapping

D1DS

Device Status Check

D1EP

Event Processing Default Configuration

D1FR

Response - Fail

D1IM

Initial Measurement Creation

D1IN

On-Demand Read (Interval)

D1LC

Load Check

D1MS

Multi-Device Status Check

D1RC

Remote Connect

D1RD

Remote Disconnect

D1RR

Response - Received

D1SC

On-Demand Read (Scalar)

D1SD

Send Device Event

D1SQ

SQI Translation

D1SR

Response - Success

D1TU

TOU Translation

D1TZ

Time Zone Translation

D1UM

UOM Translation

D1VC

Verify Commission

System Events

Service provider business objects can make use of the following system events:

•

Determine Processing Method(s) : This system event defines the algorithm used to determine the processing methods (business object or batch code) to use, based on the related entity. The Algorithm Entity for available algorithms is "Proc Method (BO) - Determine Proc Method." The base package includes the following algorithm types and algorithms for use with this system event:

Algorithm Type / Algorithm

Description

D1-BODIFFAT / D1-BODIFFAT

BO / Batch Differs By Activity Type (returns the BO code or batch code used to send activity-related information to a service provider for a processing role)

D1-BODIFFAT / D1-BOBDIFFAT

BO / Batch Differs By Activity Type (returns the BO code or batch code used to send activity-related information to a service provider for a processing role)

D1-BODIFFDT / D1-BODIFFDT

BO Differs by Device Type (returns the BO code used in the creation of device-oriented information for a service provider and processing role)

D1-BODIFFMCT / D1-BODIFFMCT

BO Differs By Measuring Component Type (returns the BO code used to create measuring component-related information for a service provider and processing role)

D1-DIFDVETC / D1-DIFDVETC

Method Differs By Device Event Category (returns the BO or outbound message type or batch process used to send device events to a service provider)

D1-OCDDT / D1-OCDDT

Outbound Communication Differs by Device Type (returns the BO used to send messages to a service provider)

D1-OMTDAT / D1-OMTDAT

Outbound Message Type Differs by Activity Type (returns the outbound message type used to create outbound messages for a service provider and processing role or message category/number if outbound message creation is not supported)

D1-OMTDCT / D1-OMTDCT

Outbound Message Type Differs By Communication Type (returns the outbound message type used to create outbound messages for a service provider and processing role or message category/number if outbound message creation is not supported))

Configuration Options

This section outlines specific types of BO Options and System Events used by service provider business objects.

Business Object Options

Service provider business objects can make use of the following business object options:

•

Applicable Processing Role : This option defines the processing role for the processing method. Valid values are defined as values for the PROC_ROLE_FLG lookup field. The base package includes the following options:

Lookup FIeld Value

Description

D1AM

Obtain AMI Device Identifier

D1BR

Bulk Response

D1DA

Activity Notification

D1DC

Device Commission

D1DD

Device Decommission

D1DM

Device Event Mapping

D1DS

Device Status Check

D1EP

Event Processing Default Configuration

D1FR

Response - Fail

D1IM

Initial Measurement Creation

D1IN

On-Demand Read (Interval)

D1LC

Load Check

D1MS

Multi-Device Status Check

D1RC

Remote Connect

D1RD

Remote Disconnect

D1RR

Response - Received

D1SC

On-Demand Read (Scalar)

D1SD

Send Device Event

D1SQ

SQI Translation

D1SR

Response - Success

D1TU

TOU Translation

D1TZ

Time Zone Translation

D1UM

UOM Translation

D1VC

Verify Commission

System Events

Service provider business objects can make use of the following system events:

•

Determine Processing Method(s) : This system event defines the algorithm used to determine the processing methods (business object or batch code) to use, based on the related entity. The Algorithm Entity for available algorithms is "Proc Method (BO) - Determine Proc Method." The base package includes the following algorithm types and algorithms for use with this system event:

Algorithm Type / Algorithm

Description

D1-BODIFFAT / D1-BODIFFAT

BO / Batch Differs By Activity Type (returns the BO code or batch code used to send activity-related information to a service provider for a processing role)

D1-BODIFFAT / D1-BOBDIFFAT

BO / Batch Differs By Activity Type (returns the BO code or batch code used to send activity-related information to a service provider for a processing role)

D1-BODIFFDT / D1-BODIFFDT

BO Differs by Device Type (returns the BO code used in the creation of device-oriented information for a service provider and processing role)

D1-BODIFFMCT / D1-BODIFFMCT

BO Differs By Measuring Component Type (returns the BO code used to create measuring component-related information for a service provider and processing role)

D1-DIFDVETC / D1-DIFDVETC

Method Differs By Device Event Category (returns the BO or outbound message type or batch process used to send device events to a service provider)

D1-OCDDT / D1-OCDDT

Outbound Communication Differs by Device Type (returns the BO used to send messages to a service provider)

D1-OMTDAT / D1-OMTDAT

Outbound Message Type Differs by Activity Type (returns the outbound message type used to create outbound messages for a service provider and processing role or message category/number if outbound message creation is not supported)

D1-OMTDCT / D1-OMTDCT

Outbound Message Type Differs By Communication Type (returns the outbound message type used to create outbound messages for a service provider and processing role or message category/number if outbound message creation is not supported))

Configuration Options

This section outlines specific types of BO Options and System Events used by service provider business objects.

Business Object Options

Service provider business objects can make use of the following business object options:

•

Applicable Processing Role : This option defines the processing role for the processing method. Valid values are defined as values for the PROC_ROLE_FLG lookup field. The base package includes the following options:

Lookup FIeld Value

Description

D1AM

Obtain AMI Device Identifier

D1BR

Bulk Response

D1DA

Activity Notification

D1DC

Device Commission

D1DD

Device Decommission

D1DM

Device Event Mapping

D1DS

Device Status Check

D1EP

Event Processing Default Configuration

D1FR

Response - Fail

D1IM

Initial Measurement Creation

D1IN

On-Demand Read (Interval)

D1LC

Load Check

D1MS

Multi-Device Status Check

D1RC

Remote Connect

D1RD

Remote Disconnect

D1RR

Response - Received

D1SC

On-Demand Read (Scalar)

D1SD

Send Device Event

D1SQ

SQI Translation

D1SR

Response - Success

D1TU

TOU Translation

D1TZ

Time Zone Translation

D1UM

UOM Translation

D1VC

Verify Commission

System Events

Service provider business objects can make use of the following system events:

•

Determine Processing Method(s) : This system event defines the algorithm used to determine the processing methods (business object or batch code) to use, based on the related entity. The Algorithm Entity for available algorithms is "Proc Method (BO) - Determine Proc Method." The base package includes the following algorithm types and algorithms for use with this system event:

Algorithm Type / Algorithm

Description

D1-BODIFFAT / D1-BODIFFAT

BO / Batch Differs By Activity Type (returns the BO code or batch code used to send activity-related information to a service provider for a processing role)

D1-BODIFFAT / D1-BOBDIFFAT

BO / Batch Differs By Activity Type (returns the BO code or batch code used to send activity-related information to a service provider for a processing role)

D1-BODIFFDT / D1-BODIFFDT

BO Differs by Device Type (returns the BO code used in the creation of device-oriented information for a service provider and processing role)

D1-BODIFFMCT / D1-BODIFFMCT

BO Differs By Measuring Component Type (returns the BO code used to create measuring component-related information for a service provider and processing role)

D1-DIFDVETC / D1-DIFDVETC

Method Differs By Device Event Category (returns the BO or outbound message type or batch process used to send device events to a service provider)

D1-OCDDT / D1-OCDDT

Outbound Communication Differs by Device Type (returns the BO used to send messages to a service provider)

D1-OMTDAT / D1-OMTDAT

Outbound Message Type Differs by Activity Type (returns the outbound message type used to create outbound messages for a service provider and processing role or message category/number if outbound message creation is not supported)

D1-OMTDCT / D1-OMTDCT

Outbound Message Type Differs By Communication Type (returns the outbound message type used to create outbound messages for a service provider and processing role or message category/number if outbound message creation is not supported))

Example Processing Method - D1-HowToCreateMCInformation

The table below lists the details of the D1-HowToCreateMCInformation business object.

Option

Description

Business Object

D1-HowToCreateMCInformation

Description

How to Create MC Related Information

Maintenance Object

D1-PROCMETHD (Processing Method)

Parent Business Object

D1-AbstractProcessingMethod

Lifecycle Business Object

Generic Processing Method

Application Service

D1-PROCMETHD (Processing Method MO)

Instance Control

Allow New Instances

Options

•

Applicable Processing Role: D1IM

•

Portal Navigation Option: d1svcproTabMenu (Service Provider)

•

Maintenance UI Map: D1-HowToCreateMCInfoMaint (How To Crt MC Related Info - Maintenance)

Algorithms

•

Determine Processing Method(s): D1-BODIFFMCT (BO Differs by Measuring Component Type)

•

Validation: D1-PROMTHVAL (Validate Processing Method)

Use the Business Object portal to view additional details concerning this business object.

Configuring Service Point and Device Installation Objects

This section provides high-level overviews of the steps involved in configuring custom service points, contacts, install events, service providers, and activities. See Configuration Process Overview in Chapter One for a high-level overview of the overall configuration process.

Note : The procedures below focus on specific configuration tasks and options related to each of the objects described in this chapter, and do not address all the steps involved in creating business objects, UI maps, algorithms, etc. For more information about these subjects, refer to the Oracle Utilities Application Framework documentation.

Configuring Custom Service Points

Configuring custom service points involves the following steps:

1.

Design the service point business objects you will need to create for your implementation, including the data and processing required for each.

2.

Create the custom service point-related configuration objects required for your business objects, including:

Business Object Options : Create algorithms for the following business object options:

•

Process Measurement Cycle

3.

Create your service point business objects, referencing the configuration objects created above as appropriate.

4.

Set up admin records that define the service point types you will use in your implementation.

Configuring Custom Contacts

Configuring custom contacts involves the following steps:

1.

Design the contact business objects you will need to create for your implementation, including the data and processing required for each.

2.

Create the custom contact-related configuration objects required for your business objects.

3.

Set up admin records that define the contact types you will use in your implementation.

Configuring Custom Install Events

Configuring custom install events involves the following steps:

1.

Design the install event business objects you will need to create for your implementation, including the data and processing required for each.

2.

Create the custom install event-related configuration objects required for your business objects.

Configuring Custom Service Providers

Configuring custom service providers involves the following steps:

1.

Design the service provider business objects you will need to create for your implementation, including the data and processing required for each.

2.

Create the custom service provider-related configuration objects required for your business objects, including:

Processing Methods : Create processing method business objects for use with each service provider.

3.

Create your service provider business objects, referencing the configuration objects created above as appropriate.

Note : Service provider business objects should reference D1-ServiceProvider as their Parent Business Object.

Configuring Custom Processing Methods

Configuring custom processing methods involves the following steps:

1.

Design the processing method business objects you will need to create for your implementation, including the data and processing required for each.

2.

Create the custom processing method-related configuration objects required for your business objects, including:

System Events : Create algorithms for the following system events:

•

Determine Processing Method(s)

3.

Create your processing method provider business objects, referencing the configuration objects created above as appropriate.

Note : Processing method business objects should reference D1-AbstractProcessingMethod as their Parent Business Object.

Measurement Data

This chapter provides descriptions of initial and final measurement data, including:

•

Understanding Initial Measurement Data and Final Measurements

•

Initial Measurement Data In Detail

•

Measurements In Detail

•

Configuring Initial Measurements and Measurements

Understanding Initial Measurement Data and Final Measurements

This section provides an overview of initial measurements and finals measurements and how they are used in Oracle Utilities Service and Measurement Data Foundation and Oracle Utilities Meter Data Managemen, including:

•

Initial Measurement Data

•

Final Measurements

•

Daylight Saving Time Support

Initial Measurement Data

Measurements read from a measuring component are referred to as "initial measurement data" (or initial measurements) and are used to record how much of the quantity (defined by UOM, TOU, and SQI) measured by the measuring component was consumed.

Initial measurement data for scalar measuring components contain a single "reading" or value, while initial measurement data for interval measuring components can contain multiple readings, one for each interval that falls between the start time and stop time of the measurement.

At a simple level, initial measurement data goes through the following process:

1.

Initial measurements are loaded into the system.

2.

Initial measurement data is validated, edited, and estimated.

3.

Initial measurements are converted into final measurements.

4.

Final measurements are used to calculate usage (bill determinants, etc.).

Creating Initial Measurements

The IMD Seeder business object (D1-IMDSeeder) is used to create initial measurements (via instantiating initial measurement business objects), based on the head-end system sending the measurement. The "Initial Measurement Creation" processing method defined for the head-end system service provider defines the specific type of initial measurement to create. If for some reason an initial measurement can’t be created, an instance of the IMD Seeder business object is created to allow tracking of the error (and once the error is resolved, the IMD Seeder instance can be reprocessed.

The IMD Seeder business object determines the service provider and measuring component for the measurement (based on attributes supplied in the incoming reading, such as device ID, external reference ID, etc.). This is performed by the "Derive Service Provider and Measuring Component" pre-processing algorithm (D1-DER-SPRMC).

If the service provider is not specified on the device, the algorithm tries to derive it from the device type. Otherwise, it attempts to derive the service provider from the measurement cycle route from the service point at which the device is installed (if available).

The IMD Seeder also ensures that the Start and End Date/Time fields on the initial measurement are populated, deriving them from the incoming reading if necessary. This step is performed by the "Derive IMD Date/Time Values" pre-processing algorithm (D1-VALDR-INP).

Critical Validations

The IMD Seeder also performs a series of critical validations to ensure that the incokming reading contains valid data. These critical validations include validating that the device identifier supplied is valid and exists in the system, and performing Undercount and Overcount checks for interval readings.

•

Device Identifier : Device identifier checks validate that the device identifier provided with the measurement is valid. Device identifiers can include serial number, badge number, channel ID, etc.

•

Undercount : An undercount occurs when an interval initial measurement contains fewer interval values than approrpriate based on the interval size (or seconds-per-interval, or SPI) and the Start and End Date/Time values. For example, if an initial measurement has an interval size of one hour (or an SPI of 3600), and a Start Date/Time is October 27, 2011 and End Date/Time of October 28, 2011 (a total duration of 1 day), it should contain 24 interval values. If it contained less than 24 interval values, it could consitute an undercount.

•

Overcount : An overcount occurs when an interval initial measurement contains more interval values than approrpriate based on the interval size (or seconds-per-interval, or SPI) and the Start and End Date/Time values. For example, if an initial measurement has an interval size of one hour (or an SPI of 3600), and a Start Date/Time is October 27, 2011 and End Date/Time of October 28, 2011 (a total duration of 1 day), it should contain 24 interval values. If it contained more than 24 interval values, it could consitute an overcount.

If an incoming interval initial measurement contains either an invalid device identifier, an undercount, or an overcount, the measurement is rejected, and an instance of the IMD Seeder business object is created. Undercount and Overcount checks are performed by the "Perform Date/Time Adjustments and Undercount/Overcount Check" pre-processing algorithm (D1-DODTTMADJ).

Time Zone Translation

If your organization receives initial measurement from a source that provides its data in a different time zone than the one in which the data will be stored in Oracle Utilities Meter Data Management, a translation can be performed to translate the time zone from an external time zone identifier to one configured within the application. This translation is defined via the Head-End Time Zone to Standard Mapping extendable lookup.

Validation, Editing, and Estimation

Once received into the system, initial measurements are subject to validation, editing, and estimation. This process involves the following:

•

Validation : Validates that the initial measurement data is within expected tolerances, and is correct

•

Editing : If the initial measurement data is wrong in some way, the data can be automatically changed.

•

Estimation : If initial measurement data is incomplete (for example, if one or more interval values within an interval measurement are missing), missing values can be automatically estimated.

As noted above, the values recorded in an initial measurement can change during the validation, editing, and estimation processing, and exceptions can be raised if initial measurements are wrong in some way (such as out-of-tolerance quantities, incorrect values, etc.).

Note : The validation, editing, and estimation process is referred to as VEE, and is described in more detail in a later chapter.

Skipping VEE Processing - High Quality Check for Interval Initial Measurements

Execution of VEE rules is performed by an Enter algorithm on the "VEE Complete" state of the initial measurement business object. For interval initial measurements, the "High Quality Check - Vector Band Based" (D1-HIGHQUALV) algorithm can be used to skip VEE processing and transition the initial measurement directly to the "Finalized" state.

This algorithm checks whether the intervals within an initial measurement are considered to be of "high quality" (defined below), and if they are considered "high quality", the algorithm transitions the current initial measurement directly to the "Finalized" state.

An interval initial measurement is considered to be of "high quality" if the following conditions are met:

•

There are no missing intervals in the initial measurement

•

All interval values are within a range that extends above and below final interval values for the corresponding intervals from the previous reading. The range is defined by the "Low Tolerance" and "High Tolerance" algorithm parameters. These parameters define mutipliers that are applied to the corresponding interval from the previous reading. The "Low Tolerance" is subtracted from the previous reading’s final measurement, and the "High Tolerance" is added the the previous reading’s final measurement to define the range within which each interval must fall.

For example, if the previous reading’s final measurement value at 1:00 AM was 20, and the "Low Tolerance" parameter is set to 0.2 and the "High Tolerance" parameter is set to 0.25, the initial measurement’s value at 1:00 AM must be between between 16 (20 - 0.2*20) and 25 (20 + 0.25*20).

•

All intervals have a condition code that falls between the range defined by the "Default Bottom Range Condition Value" and "Default Top Range Condition Value" algorithm parameters.

If the initial measurement fails any part of the high quality assessment, the routine simply exits.

Pre VEE and Post VEE Quantities

Initial measurement data contains both the original and final versions of the quantities recorded by the measuring component.

•

Pre VEE quantities are consumption values derived from the measurements recorded by the head-end system or meter reader.

•

Post VEE quantities are the "final" values, after VEE processing.

Pre VEE and Post VEE quantities in an initial measurement often differ based on a number of conditions, including:

1.

The measuring component has a multiplier other than 1.

In this case, the Post VEE value is equal to the Pre VEE value times the multiplier.

2.

The installation event has a constant other than 1.

In this case, the Post VEE value is equal to the Pre VEE value times the installation constant.

3.

VEE rules have changed the quantities because they are missing or obviously wrong

In this, the Pre VEE values are adjusted based on the specifics of the VEE rules applied to the initial measurement to create the Post VEE values

4.

Manual changes by a user.

Condition Codes

In addition to recorded consumption values, measurements also have condition codes, used to indicate the source and quality of a measurement. For example:

•

Regularly recorded measurements might have a condition code of "Regular"

•

Missing measurements might have a condition code of "Missing"

•

Estimated measurements might have a condition code of "External Estimated" or "System Estimated" based on where the estimation was performed.

Both Pre VEE and Post VEE values have their own condition code, which can also change during VEE processing. For example, consider the following sample measurements from an interval measuring component:

Date / Time

Pre VEE Value

Pre VEE Condition

Post VEE Value

Post VEE Condition

01/01/2010 3:00 PM

14.678

Regular

15.1

Regular

01/01/2010 4:00 PM

Missing

20

Estimated

01/01/2010 5:00 PM

13.12

Regular

13.41

Regular

01/01/2010 6:00 PM

150.12

Regular

14.12

Estimated

For the 4:00 PM interval, note the Pre VEE condition indicates the interval is missing and the Post VEE condition highlights that it was estimated.

For the 6:00 PM interval (containing a spike, or an interval with conspicuously high usage relative to surrounding intervals), note that the system head-end (the system that recorded the measurement) indicated the interval value was fine (Pre VEE is regular), but the VEE process smoothed it, and set the Post VEE condition to "Estimated."

Condition Codes Extendable Lookup

Condition codes are defined in the Measurement Condition extendable lookup (D1-MeasurementConditionLookup). Base package condition codes delivered in this extendable lookup include the following:

Condition Code (Value)

Description

100000

No Read - System

101000

No Read - Outage

201000

Missing

301000

System Estimate

401000

External Estimate

402000

Office Estimate

501000

Regular

901000

Super

Additional condition codes can be added to this extendable lookup to meet requirements specific to individual implementations. Gaps between the base package condition code values allow custom condition codes to be added that represent data with conditions that fall between the base package conditions. For example, a condition code to indicate that the measurement was estimated based on partially incomplete data (and is considered to be of worse quality than "System Estimate", but better than "Missing") would fall somewhere between 201000 and 301000.

As a general rule, condition codes used to represent bad data or error conditions should be smaller than condition codes used to represent good data.’

Reader Remarks and Scalar Measurements

Initial measurements for manually-read scalar meters can create reader remarks. Reader remarks are a specific type of device event used to capture and/or record specific events or circumstances encountered when a meter reader is manually reading scalar meters.

Reader remark types are submitted with scalar initial measurements when received from a head-end system or meter read collection system. Reader remarks are NOT uploaded along with other device events. Reader remarks are ALWAYS associated with a scalar initial measurement.

Understanding Reader Remark Processing

This section provides an overview of the process that takes place when reader remarks are received within a scalar measurement. For each step in the process, the table below provides a brief description of the processing that takes place, and lists the specific objects used by the Service and Measurement Data Foundation

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

Step

Process

Service and Measurement Data Foundation Objects

1.

The system receives an initial measurement from a manually-read scalar device that contains one or more reader remark types.

The base package "Initial Load IMD (Scalar)" (D1-IntialLoadIMDScalar) business object supports inclusion of one or more reader remark types.

2.

When the initial measurement enters the Finalized state, an Enter algorithm creates a reader remark for each reader remark type included in the initial measurement.

Note: Creation of reader remarks does NOT make use of device event mapping extendable lookups.

Algorithm: D1-CRE-RR (Create Reader Remark)

3.

Reader remarks begin in the Pending state. They are transitioned to the Execute state either manually or via batch processing.

The Execute state contains a number of Enter algorithms that perform the following

•

Determine if the reader remark is eligible for processing, based on the "Eligible for Processing" flag on the reader remark type

•

Create a To Do Entry based on the "To Do Type" and "To Do Role" defined on the reader remark type

•

Create a service issue monitor based on the service issue monitor specified on the reader remark type

•

Send the reader remark to subscribing systems

Batch Control: D1-DVEVT (Device Event MO Periodic Monitor Process)

Algorithm: D1-RR-ELIG (Reader Remark Eligibility)

Algorithm: D1-CRE-RR-TD (Create To Do Entry for Reader Remark)

Algorithm: D1-DVCEVTSIM (Create Service Issue Monitor for Reader Remark)

Algorithm: D1-RRSENDSUB (Send to Subscribers for Reader Remark)

Sending Reader Remarks to Subscribing Systems

Reader remarks can be passed onto to other subscribing systems such as a customer information system (such as Oracle Utilities Customer Care and Billing), an outage system (such as Oracle Utilities Network Management System), or some other application.

Reader remarks are sent to subscribing systems when they enter the Execute state. An Enter algorithm (D1-RRSENDSUB /Send to Subscribers for Reader Remark in the base package) determines which service providers (external systems) are interested in receiving the current reader remark based upon its type and category, finds the processing method for each, and processes the device event accordingly.

The means of sending reader remark information to subscribing systems is defined in the "How to Send Device Event Related Information" processing method for the service provider representing the subscribing system. Reader remark information can be sent via outbound communication business object, outbound communication, or batch process.

The method for sending device events to subscribing systems (business object, outbound message, or batch process) is defined for the "Reader Remark" device event category, and can be overridden for individual reader remark types (including the ability to exclude specific reader remark types. In addition, a default event processing method can be also be configured that applies when methods of transmission aren't specified at the individual category level.

The "Subscribe to Device Event" business service is used to process reader remark subscription requests, and allow external applications to manage the categories of events they receive.

Reader Remarks and Service Issue Monitors

Like other device events, reader remarks can create service issue monitors. See Service Issue Monitors and Service Investigative Orders in Chapter 8: Device Communication and Device Events for more information about service issue monitors.

Subtractive Measuring Components

Initial measurement data for subtractive measuring components (such as most scalar measuring components) also typically contain start and stop readings in addition to Pre and Post VEE usage. For example, a set of initial measurements for s subtractive scalar measuring component might look like the following:

Date / Time

Start Reading

Stop Reading

Pre VEE Usage

Pre VEE Condition

Post VEE Value

Post VEE Usage

01/01/2010 3:00 PM

0

1500

1500

Regular

1515

Regular

02/2/2010 4:11 PM

1500

2100

600

Regular

606

Regular

03/03/2010 5:22 PM

2100

2900

800

Regular

808

Regular

04/01/2010 1:00 PM

2900

3500

600

Regular

606

Regular

Rollover Calculations

Subtractive measuring components can "rollover" when the reading exceeds the maximum value based on the number of dials. For example, a register with a 4 dials can record values up to 9999 before rolling over to 0000. When this occurs, consumption is calculated based on the following attributes and calculated values.

•

Rollover Threshold is the percentage of the measuring component's dial capacity at which measurements for measuring components of this type are considered to have rolled over. Dial capacity is the largest value that can be recorded for the measuring component, based on the measuring component's number of dials. For example, a measuring component with 5 dials has a dial capacity of 99999.

•

MaxDialCapacity is the maximum value for the number of dials, rounded up to the next whole multiple of 10 (or 10 raised to the power of the number of dials). For example, for a register with 4 dials, the MaxDialValue is 10000.

•

MaxAcceptableDifference is the maximum acceptable consumption that can be recorded for the register. This is equal to the MaxDialCapacity multiplied by the rollover threshold. For example, the MaxAcceptableDifference for a register with 4 dials and a rollover threshold of 90% would be 9000. If the consumption is greater than this value, the initial measurement is transitioned to the Error state.

•

Difference : The difference between the Stop Reading and Start Reading, obtained by subtracting the Start Reading from the Stop Reading. If the Difference is less than zero (<0), then add the MaxDialCapacity to calculate Rollover.

•

Rollover : The adjusted consumption for a reading on a register that has rolled over. Only applicable if the Difference (Stop Reading - Start Reading) is less than zero (<0).

•

Consumption : The calculated consumption for the reading, equal to either the Difference or Rollover. If the Difference is greater than or equal to zero, consumption is equal to the Difference. If the Difference is less than zero (<0), and the Rollover is less than or equal to the MaxAcceptableDifference, the consumption is equal to the Rollover.

Example : Consider an initial measurement with the following attributes:

•

Number of Dials: 4

•

Rollover Threshold: 90 (%)

•

Start Reading: 8900

•

Stop Reading: 0500

For this reading,

MaxDialCapacity = 10000

MaxAcceptableDifference = 9000 (10000 * .90)

Difference = 0500 (Stop Reading) - 8900 (Start Reading) or -8400

Rollover = 10000 (MaxDialCapacity) + -8400 (Difference) or 1600

Consumption is equal to 1600 (Rollover).

Estimated Initial Measurements

Over the course of time, it may happen that the system will not receive usage for a device for some period of time. When the system detects that a measuring component is missing final measurements, it can creates a initial measurement via estimation. This type of initial measurement is referred to as an estimated initial measurement (as opposed to an Initial Load or Manual initial measurement).

At a high-level, the estimation process is as follows:

•

Missing Measurements are detected by a "Period Estimation" system event algorithm on the measuring component business object

•

Estimated initial measurements are created for the "missing" time period by the "Period Estimation" system event algorithm on the measuring component business object

•

Values and consumption for the estimated initial measurements are calculated by "estimation" VEE rules.

It’s important to note that the processes that detect missing measurements do NOT themselves estimate consumption. Rather, these detection processes simply create an initial measurement and let the estimation VEE rules estimate the consumption for the initial measurement.

Detecting Missing Measurements

The detection of missing measurements occurs at different points in time for interval and scalar measuring components:

•

For interval measuring components, a dedicated batch process exists to initiate creation of estimated initial measurements

•

For manually read scalar measuring components, a usage calculation rule creates the initial measurement if it cannot find a measurement and it has been given permission to estimate. (Note: the information that follows applies primarily to interval measuring components).

The batch process that detects missing consumption for interval measuring components uses two elements on interval measurinng component type:

•

Hours Before Estimation : the number of hours after the End Date and Time of the most recent measurement that must pass before the measuring component is considered due for estimation. For example, if set to 72 hours, estimation will only take place 72 hours after the End Date and Time of the latest measurement.

•

Number of Hours to Estimate : the number of hours of measurement data that are estimated when estimation is performed for the measuring component.

If a measuring component has contiguous final measurements on/after a date and time equal to the current date/time minus the "Hours Before Estimate" value, the measuring component is not estimated.

If the measuring component does NOT have contiguous final measurements on/after a date and time equal to the current date/time minus the "Hours Before Estimate" value, the measuring component is estimated. If the measuring component is subject to estimation, measurements will be estimated through the a date and time equal to the current date/time minus the (Hours Before Estimation - Number of Hours to Estimate).

The following examples illustrate how the system determines if estimation should take place. These examples are all assume a measuring component whose measuring component type specifies an "Hours Before Estimation" of 72 (3 days) and a "Number of Hours to Estimate" of 24 (1 day).

Example 1 : On January 9, if there is contiguous consumption through January 7, estimation would not occur because consumption exists after January 6 (3 days prior to January 9). The diagram below illustrates this example:

Example 2 : On Janury 9 if contiguous consumption existed through January 2, estimation would take place because consumption does not exist through January 6 (3 days prior to January 9). In this example, consumption would be estimated for missing intervals from January 2 through January 7 (January 9 minus 48 hours (Hours Before Estimation minus Number of Hours to Estimate). Note that this assumes that period estimation had NOT been run after January 5. The diagram below illustrates this example:

Example 3 : On Janury 9 if contiguous consumption existed through January 2 and for January 5 (but NOT for January 3-4 or 6-7), two initial measurements would be created, one for January 3-4, and another for January 6-7. The diagram below illustrates this example:

Estimation Algorithms

Estimation for interval measuring components is detected and initiated by two algorithms, one on the device business object, and the other on the measuring component business object.

Devices whose measuring components are subject to periodic estimation (in most cases, interval measuring components) have a "Period Estimation" Monitor algorithm (D1-PERESTM) on their Active state. This monitoring algorithm retrieves the device's measuring component and invokes the algorithm on the "Periodic Estimation" system event on the measuring component business object. Note - the device monitoring algorithm can be configured to look at device configurations from a number of days in the past defined by an algorithm parameter. The base package includes this algorithm on the Active state of the Smart Meter (D1-SmartMeter) device business object. The "Periodic Estimation" monitor algorithm can be triggered by the "Smart Meter State Monitor Process" batch process (D1-SMMTR).

The "Periodic Estimation" System Event algorithm determines if a measuring component is missing final measurements (as described above), and if final measurements are missing, estimates initial measurements and/or creates a To Do Entry. In the base package, this algorithm is the "Create Initial Measurement and To Do Entry" algorithm (D1-CRIMTODO). Algorithm parameters can specify if an initial measurement is to be created, if an To Do Entry is to be created, and the To Do Type and Role (if applicable) for any To Do entries created. The base package includes this algorithm on the Period Estimation system event state of the Interval Channel (D1-IntervalChannel) measuring component business object.

Estimation Calculations

When new estimated initial measurements are created (for either interval or scalar measuring components), the Pre-VEE and Post-VEE values are initially set to zero. When the initial measurement enters the "VEE Complete" state, the VEE rules within the VEE group defined for the "Estimation" VEE role (defined by the "VEE Group For Estimation" field on the measuring component) calculate values and consumption for the initial measurement.

Note that the VEE rules used in this process can also include validation rules that perform validation on the estimated values and consumption. For example, the "estimation" VEE group might contain rules to estimate interval values from a profile, and then perform a sum check to validate the resulting interval measurement against measurements from a consumption reference measuring component. In this example, the sum check validation would be configured to be applied after the interval profile estimation.

Estimated initial measurements are created using "estimation" initial measurement business objects. The base package includes the Estimation IMD (Interval) and Estimation IMD (Scalar) business objects (D1-EstimationIMDInterval or D1-EstimationIMDScalar, respectively).

Initial Measurement Data

Measurements read from a measuring component are referred to as "initial measurement data" (or initial measurements) and are used to record how much of the quantity (defined by UOM, TOU, and SQI) measured by the measuring component was consumed.

Initial measurement data for scalar measuring components contain a single "reading" or value, while initial measurement data for interval measuring components can contain multiple readings, one for each interval that falls between the start time and stop time of the measurement.

At a simple level, initial measurement data goes through the following process:

1.

Initial measurements are loaded into the system.

2.

Initial measurement data is validated, edited, and estimated.

3.

Initial measurements are converted into final measurements.

4.

Final measurements are used to calculate usage (bill determinants, etc.).

Creating Initial Measurements

The IMD Seeder business object (D1-IMDSeeder) is used to create initial measurements (via instantiating initial measurement business objects), based on the head-end system sending the measurement. The "Initial Measurement Creation" processing method defined for the head-end system service provider defines the specific type of initial measurement to create. If for some reason an initial measurement can’t be created, an instance of the IMD Seeder business object is created to allow tracking of the error (and once the error is resolved, the IMD Seeder instance can be reprocessed.

The IMD Seeder business object determines the service provider and measuring component for the measurement (based on attributes supplied in the incoming reading, such as device ID, external reference ID, etc.). This is performed by the "Derive Service Provider and Measuring Component" pre-processing algorithm (D1-DER-SPRMC).

If the service provider is not specified on the device, the algorithm tries to derive it from the device type. Otherwise, it attempts to derive the service provider from the measurement cycle route from the service point at which the device is installed (if available).

The IMD Seeder also ensures that the Start and End Date/Time fields on the initial measurement are populated, deriving them from the incoming reading if necessary. This step is performed by the "Derive IMD Date/Time Values" pre-processing algorithm (D1-VALDR-INP).

Critical Validations

The IMD Seeder also performs a series of critical validations to ensure that the incokming reading contains valid data. These critical validations include validating that the device identifier supplied is valid and exists in the system, and performing Undercount and Overcount checks for interval readings.

•

Device Identifier : Device identifier checks validate that the device identifier provided with the measurement is valid. Device identifiers can include serial number, badge number, channel ID, etc.

•

Undercount : An undercount occurs when an interval initial measurement contains fewer interval values than approrpriate based on the interval size (or seconds-per-interval, or SPI) and the Start and End Date/Time values. For example, if an initial measurement has an interval size of one hour (or an SPI of 3600), and a Start Date/Time is October 27, 2011 and End Date/Time of October 28, 2011 (a total duration of 1 day), it should contain 24 interval values. If it contained less than 24 interval values, it could consitute an undercount.

•

Overcount : An overcount occurs when an interval initial measurement contains more interval values than approrpriate based on the interval size (or seconds-per-interval, or SPI) and the Start and End Date/Time values. For example, if an initial measurement has an interval size of one hour (or an SPI of 3600), and a Start Date/Time is October 27, 2011 and End Date/Time of October 28, 2011 (a total duration of 1 day), it should contain 24 interval values. If it contained more than 24 interval values, it could consitute an overcount.

If an incoming interval initial measurement contains either an invalid device identifier, an undercount, or an overcount, the measurement is rejected, and an instance of the IMD Seeder business object is created. Undercount and Overcount checks are performed by the "Perform Date/Time Adjustments and Undercount/Overcount Check" pre-processing algorithm (D1-DODTTMADJ).

Time Zone Translation

If your organization receives initial measurement from a source that provides its data in a different time zone than the one in which the data will be stored in Oracle Utilities Meter Data Management, a translation can be performed to translate the time zone from an external time zone identifier to one configured within the application. This translation is defined via the Head-End Time Zone to Standard Mapping extendable lookup.

Validation, Editing, and Estimation

Once received into the system, initial measurements are subject to validation, editing, and estimation. This process involves the following:

•

Validation : Validates that the initial measurement data is within expected tolerances, and is correct

•

Editing : If the initial measurement data is wrong in some way, the data can be automatically changed.

•

Estimation : If initial measurement data is incomplete (for example, if one or more interval values within an interval measurement are missing), missing values can be automatically estimated.

As noted above, the values recorded in an initial measurement can change during the validation, editing, and estimation processing, and exceptions can be raised if initial measurements are wrong in some way (such as out-of-tolerance quantities, incorrect values, etc.).

Note : The validation, editing, and estimation process is referred to as VEE, and is described in more detail in a later chapter.

Skipping VEE Processing - High Quality Check for Interval Initial Measurements

Execution of VEE rules is performed by an Enter algorithm on the "VEE Complete" state of the initial measurement business object. For interval initial measurements, the "High Quality Check - Vector Band Based" (D1-HIGHQUALV) algorithm can be used to skip VEE processing and transition the initial measurement directly to the "Finalized" state.

This algorithm checks whether the intervals within an initial measurement are considered to be of "high quality" (defined below), and if they are considered "high quality", the algorithm transitions the current initial measurement directly to the "Finalized" state.

An interval initial measurement is considered to be of "high quality" if the following conditions are met:

•

There are no missing intervals in the initial measurement

•

All interval values are within a range that extends above and below final interval values for the corresponding intervals from the previous reading. The range is defined by the "Low Tolerance" and "High Tolerance" algorithm parameters. These parameters define mutipliers that are applied to the corresponding interval from the previous reading. The "Low Tolerance" is subtracted from the previous reading’s final measurement, and the "High Tolerance" is added the the previous reading’s final measurement to define the range within which each interval must fall.

For example, if the previous reading’s final measurement value at 1:00 AM was 20, and the "Low Tolerance" parameter is set to 0.2 and the "High Tolerance" parameter is set to 0.25, the initial measurement’s value at 1:00 AM must be between between 16 (20 - 0.2*20) and 25 (20 + 0.25*20).

•

All intervals have a condition code that falls between the range defined by the "Default Bottom Range Condition Value" and "Default Top Range Condition Value" algorithm parameters.

If the initial measurement fails any part of the high quality assessment, the routine simply exits.

Pre VEE and Post VEE Quantities

Initial measurement data contains both the original and final versions of the quantities recorded by the measuring component.

•

Pre VEE quantities are consumption values derived from the measurements recorded by the head-end system or meter reader.

•

Post VEE quantities are the "final" values, after VEE processing.

Pre VEE and Post VEE quantities in an initial measurement often differ based on a number of conditions, including:

1.

The measuring component has a multiplier other than 1.

In this case, the Post VEE value is equal to the Pre VEE value times the multiplier.

2.

The installation event has a constant other than 1.

In this case, the Post VEE value is equal to the Pre VEE value times the installation constant.

3.

VEE rules have changed the quantities because they are missing or obviously wrong

In this, the Pre VEE values are adjusted based on the specifics of the VEE rules applied to the initial measurement to create the Post VEE values

4.

Manual changes by a user.

Condition Codes

In addition to recorded consumption values, measurements also have condition codes, used to indicate the source and quality of a measurement. For example:

•

Regularly recorded measurements might have a condition code of "Regular"

•

Missing measurements might have a condition code of "Missing"

•

Estimated measurements might have a condition code of "External Estimated" or "System Estimated" based on where the estimation was performed.

Both Pre VEE and Post VEE values have their own condition code, which can also change during VEE processing. For example, consider the following sample measurements from an interval measuring component:

Date / Time

Pre VEE Value

Pre VEE Condition

Post VEE Value

Post VEE Condition

01/01/2010 3:00 PM

14.678

Regular

15.1

Regular

01/01/2010 4:00 PM

Missing

20

Estimated

01/01/2010 5:00 PM

13.12

Regular

13.41

Regular

01/01/2010 6:00 PM

150.12

Regular

14.12

Estimated

For the 4:00 PM interval, note the Pre VEE condition indicates the interval is missing and the Post VEE condition highlights that it was estimated.

For the 6:00 PM interval (containing a spike, or an interval with conspicuously high usage relative to surrounding intervals), note that the system head-end (the system that recorded the measurement) indicated the interval value was fine (Pre VEE is regular), but the VEE process smoothed it, and set the Post VEE condition to "Estimated."

Condition Codes Extendable Lookup

Condition codes are defined in the Measurement Condition extendable lookup (D1-MeasurementConditionLookup). Base package condition codes delivered in this extendable lookup include the following:

Condition Code (Value)

Description

100000

No Read - System

101000

No Read - Outage

201000

Missing

301000

System Estimate

401000

External Estimate

402000

Office Estimate

501000

Regular

901000

Super

Additional condition codes can be added to this extendable lookup to meet requirements specific to individual implementations. Gaps between the base package condition code values allow custom condition codes to be added that represent data with conditions that fall between the base package conditions. For example, a condition code to indicate that the measurement was estimated based on partially incomplete data (and is considered to be of worse quality than "System Estimate", but better than "Missing") would fall somewhere between 201000 and 301000.

As a general rule, condition codes used to represent bad data or error conditions should be smaller than condition codes used to represent good data.’

Reader Remarks and Scalar Measurements

Initial measurements for manually-read scalar meters can create reader remarks. Reader remarks are a specific type of device event used to capture and/or record specific events or circumstances encountered when a meter reader is manually reading scalar meters.

Reader remark types are submitted with scalar initial measurements when received from a head-end system or meter read collection system. Reader remarks are NOT uploaded along with other device events. Reader remarks are ALWAYS associated with a scalar initial measurement.

Understanding Reader Remark Processing

This section provides an overview of the process that takes place when reader remarks are received within a scalar measurement. For each step in the process, the table below provides a brief description of the processing that takes place, and lists the specific objects used by the Service and Measurement Data Foundation

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

Step

Process

Service and Measurement Data Foundation Objects

1.

The system receives an initial measurement from a manually-read scalar device that contains one or more reader remark types.

The base package "Initial Load IMD (Scalar)" (D1-IntialLoadIMDScalar) business object supports inclusion of one or more reader remark types.

2.

When the initial measurement enters the Finalized state, an Enter algorithm creates a reader remark for each reader remark type included in the initial measurement.

Note: Creation of reader remarks does NOT make use of device event mapping extendable lookups.

Algorithm: D1-CRE-RR (Create Reader Remark)

3.

Reader remarks begin in the Pending state. They are transitioned to the Execute state either manually or via batch processing.

The Execute state contains a number of Enter algorithms that perform the following

•

Determine if the reader remark is eligible for processing, based on the "Eligible for Processing" flag on the reader remark type

•

Create a To Do Entry based on the "To Do Type" and "To Do Role" defined on the reader remark type

•

Create a service issue monitor based on the service issue monitor specified on the reader remark type

•

Send the reader remark to subscribing systems

Batch Control: D1-DVEVT (Device Event MO Periodic Monitor Process)

Algorithm: D1-RR-ELIG (Reader Remark Eligibility)

Algorithm: D1-CRE-RR-TD (Create To Do Entry for Reader Remark)

Algorithm: D1-DVCEVTSIM (Create Service Issue Monitor for Reader Remark)

Algorithm: D1-RRSENDSUB (Send to Subscribers for Reader Remark)

Sending Reader Remarks to Subscribing Systems

Reader remarks can be passed onto to other subscribing systems such as a customer information system (such as Oracle Utilities Customer Care and Billing), an outage system (such as Oracle Utilities Network Management System), or some other application.

Reader remarks are sent to subscribing systems when they enter the Execute state. An Enter algorithm (D1-RRSENDSUB /Send to Subscribers for Reader Remark in the base package) determines which service providers (external systems) are interested in receiving the current reader remark based upon its type and category, finds the processing method for each, and processes the device event accordingly.

The means of sending reader remark information to subscribing systems is defined in the "How to Send Device Event Related Information" processing method for the service provider representing the subscribing system. Reader remark information can be sent via outbound communication business object, outbound communication, or batch process.

The method for sending device events to subscribing systems (business object, outbound message, or batch process) is defined for the "Reader Remark" device event category, and can be overridden for individual reader remark types (including the ability to exclude specific reader remark types. In addition, a default event processing method can be also be configured that applies when methods of transmission aren't specified at the individual category level.

The "Subscribe to Device Event" business service is used to process reader remark subscription requests, and allow external applications to manage the categories of events they receive.

Reader Remarks and Service Issue Monitors

Like other device events, reader remarks can create service issue monitors. See Service Issue Monitors and Service Investigative Orders in Chapter 8: Device Communication and Device Events for more information about service issue monitors.

Subtractive Measuring Components

Initial measurement data for subtractive measuring components (such as most scalar measuring components) also typically contain start and stop readings in addition to Pre and Post VEE usage. For example, a set of initial measurements for s subtractive scalar measuring component might look like the following:

Date / Time

Start Reading

Stop Reading

Pre VEE Usage

Pre VEE Condition

Post VEE Value

Post VEE Usage

01/01/2010 3:00 PM

0

1500

1500

Regular

1515

Regular

02/2/2010 4:11 PM

1500

2100

600

Regular

606

Regular

03/03/2010 5:22 PM

2100

2900

800

Regular

808

Regular

04/01/2010 1:00 PM

2900

3500

600

Regular

606

Regular

Rollover Calculations

Subtractive measuring components can "rollover" when the reading exceeds the maximum value based on the number of dials. For example, a register with a 4 dials can record values up to 9999 before rolling over to 0000. When this occurs, consumption is calculated based on the following attributes and calculated values.

•

Rollover Threshold is the percentage of the measuring component's dial capacity at which measurements for measuring components of this type are considered to have rolled over. Dial capacity is the largest value that can be recorded for the measuring component, based on the measuring component's number of dials. For example, a measuring component with 5 dials has a dial capacity of 99999.

•

MaxDialCapacity is the maximum value for the number of dials, rounded up to the next whole multiple of 10 (or 10 raised to the power of the number of dials). For example, for a register with 4 dials, the MaxDialValue is 10000.

•

MaxAcceptableDifference is the maximum acceptable consumption that can be recorded for the register. This is equal to the MaxDialCapacity multiplied by the rollover threshold. For example, the MaxAcceptableDifference for a register with 4 dials and a rollover threshold of 90% would be 9000. If the consumption is greater than this value, the initial measurement is transitioned to the Error state.

•

Difference : The difference between the Stop Reading and Start Reading, obtained by subtracting the Start Reading from the Stop Reading. If the Difference is less than zero (<0), then add the MaxDialCapacity to calculate Rollover.

•

Rollover : The adjusted consumption for a reading on a register that has rolled over. Only applicable if the Difference (Stop Reading - Start Reading) is less than zero (<0).

•

Consumption : The calculated consumption for the reading, equal to either the Difference or Rollover. If the Difference is greater than or equal to zero, consumption is equal to the Difference. If the Difference is less than zero (<0), and the Rollover is less than or equal to the MaxAcceptableDifference, the consumption is equal to the Rollover.

Example : Consider an initial measurement with the following attributes:

•

Number of Dials: 4

•

Rollover Threshold: 90 (%)

•

Start Reading: 8900

•

Stop Reading: 0500

For this reading,

MaxDialCapacity = 10000

MaxAcceptableDifference = 9000 (10000 * .90)

Difference = 0500 (Stop Reading) - 8900 (Start Reading) or -8400

Rollover = 10000 (MaxDialCapacity) + -8400 (Difference) or 1600

Consumption is equal to 1600 (Rollover).

Estimated Initial Measurements

Over the course of time, it may happen that the system will not receive usage for a device for some period of time. When the system detects that a measuring component is missing final measurements, it can creates a initial measurement via estimation. This type of initial measurement is referred to as an estimated initial measurement (as opposed to an Initial Load or Manual initial measurement).

At a high-level, the estimation process is as follows:

•

Missing Measurements are detected by a "Period Estimation" system event algorithm on the measuring component business object

•

Estimated initial measurements are created for the "missing" time period by the "Period Estimation" system event algorithm on the measuring component business object

•

Values and consumption for the estimated initial measurements are calculated by "estimation" VEE rules.

It’s important to note that the processes that detect missing measurements do NOT themselves estimate consumption. Rather, these detection processes simply create an initial measurement and let the estimation VEE rules estimate the consumption for the initial measurement.

Detecting Missing Measurements

The detection of missing measurements occurs at different points in time for interval and scalar measuring components:

•

For interval measuring components, a dedicated batch process exists to initiate creation of estimated initial measurements

•

For manually read scalar measuring components, a usage calculation rule creates the initial measurement if it cannot find a measurement and it has been given permission to estimate. (Note: the information that follows applies primarily to interval measuring components).

The batch process that detects missing consumption for interval measuring components uses two elements on interval measurinng component type:

•

Hours Before Estimation : the number of hours after the End Date and Time of the most recent measurement that must pass before the measuring component is considered due for estimation. For example, if set to 72 hours, estimation will only take place 72 hours after the End Date and Time of the latest measurement.

•

Number of Hours to Estimate : the number of hours of measurement data that are estimated when estimation is performed for the measuring component.

If a measuring component has contiguous final measurements on/after a date and time equal to the current date/time minus the "Hours Before Estimate" value, the measuring component is not estimated.

If the measuring component does NOT have contiguous final measurements on/after a date and time equal to the current date/time minus the "Hours Before Estimate" value, the measuring component is estimated. If the measuring component is subject to estimation, measurements will be estimated through the a date and time equal to the current date/time minus the (Hours Before Estimation - Number of Hours to Estimate).

The following examples illustrate how the system determines if estimation should take place. These examples are all assume a measuring component whose measuring component type specifies an "Hours Before Estimation" of 72 (3 days) and a "Number of Hours to Estimate" of 24 (1 day).

Example 1 : On January 9, if there is contiguous consumption through January 7, estimation would not occur because consumption exists after January 6 (3 days prior to January 9). The diagram below illustrates this example:

Example 2 : On Janury 9 if contiguous consumption existed through January 2, estimation would take place because consumption does not exist through January 6 (3 days prior to January 9). In this example, consumption would be estimated for missing intervals from January 2 through January 7 (January 9 minus 48 hours (Hours Before Estimation minus Number of Hours to Estimate). Note that this assumes that period estimation had NOT been run after January 5. The diagram below illustrates this example:

Example 3 : On Janury 9 if contiguous consumption existed through January 2 and for January 5 (but NOT for January 3-4 or 6-7), two initial measurements would be created, one for January 3-4, and another for January 6-7. The diagram below illustrates this example:

Estimation Algorithms

Estimation for interval measuring components is detected and initiated by two algorithms, one on the device business object, and the other on the measuring component business object.

Devices whose measuring components are subject to periodic estimation (in most cases, interval measuring components) have a "Period Estimation" Monitor algorithm (D1-PERESTM) on their Active state. This monitoring algorithm retrieves the device's measuring component and invokes the algorithm on the "Periodic Estimation" system event on the measuring component business object. Note - the device monitoring algorithm can be configured to look at device configurations from a number of days in the past defined by an algorithm parameter. The base package includes this algorithm on the Active state of the Smart Meter (D1-SmartMeter) device business object. The "Periodic Estimation" monitor algorithm can be triggered by the "Smart Meter State Monitor Process" batch process (D1-SMMTR).

The "Periodic Estimation" System Event algorithm determines if a measuring component is missing final measurements (as described above), and if final measurements are missing, estimates initial measurements and/or creates a To Do Entry. In the base package, this algorithm is the "Create Initial Measurement and To Do Entry" algorithm (D1-CRIMTODO). Algorithm parameters can specify if an initial measurement is to be created, if an To Do Entry is to be created, and the To Do Type and Role (if applicable) for any To Do entries created. The base package includes this algorithm on the Period Estimation system event state of the Interval Channel (D1-IntervalChannel) measuring component business object.

Estimation Calculations

When new estimated initial measurements are created (for either interval or scalar measuring components), the Pre-VEE and Post-VEE values are initially set to zero. When the initial measurement enters the "VEE Complete" state, the VEE rules within the VEE group defined for the "Estimation" VEE role (defined by the "VEE Group For Estimation" field on the measuring component) calculate values and consumption for the initial measurement.

Note that the VEE rules used in this process can also include validation rules that perform validation on the estimated values and consumption. For example, the "estimation" VEE group might contain rules to estimate interval values from a profile, and then perform a sum check to validate the resulting interval measurement against measurements from a consumption reference measuring component. In this example, the sum check validation would be configured to be applied after the interval profile estimation.

Estimated initial measurements are created using "estimation" initial measurement business objects. The base package includes the Estimation IMD (Interval) and Estimation IMD (Scalar) business objects (D1-EstimationIMDInterval or D1-EstimationIMDScalar, respectively).

Initial Measurement Data

Measurements read from a measuring component are referred to as "initial measurement data" (or initial measurements) and are used to record how much of the quantity (defined by UOM, TOU, and SQI) measured by the measuring component was consumed.

Initial measurement data for scalar measuring components contain a single "reading" or value, while initial measurement data for interval measuring components can contain multiple readings, one for each interval that falls between the start time and stop time of the measurement.

At a simple level, initial measurement data goes through the following process:

1.

Initial measurements are loaded into the system.

2.

Initial measurement data is validated, edited, and estimated.

3.

Initial measurements are converted into final measurements.

4.

Final measurements are used to calculate usage (bill determinants, etc.).

Creating Initial Measurements

The IMD Seeder business object (D1-IMDSeeder) is used to create initial measurements (via instantiating initial measurement business objects), based on the head-end system sending the measurement. The "Initial Measurement Creation" processing method defined for the head-end system service provider defines the specific type of initial measurement to create. If for some reason an initial measurement can’t be created, an instance of the IMD Seeder business object is created to allow tracking of the error (and once the error is resolved, the IMD Seeder instance can be reprocessed.

The IMD Seeder business object determines the service provider and measuring component for the measurement (based on attributes supplied in the incoming reading, such as device ID, external reference ID, etc.). This is performed by the "Derive Service Provider and Measuring Component" pre-processing algorithm (D1-DER-SPRMC).

If the service provider is not specified on the device, the algorithm tries to derive it from the device type. Otherwise, it attempts to derive the service provider from the measurement cycle route from the service point at which the device is installed (if available).

The IMD Seeder also ensures that the Start and End Date/Time fields on the initial measurement are populated, deriving them from the incoming reading if necessary. This step is performed by the "Derive IMD Date/Time Values" pre-processing algorithm (D1-VALDR-INP).

Critical Validations

The IMD Seeder also performs a series of critical validations to ensure that the incokming reading contains valid data. These critical validations include validating that the device identifier supplied is valid and exists in the system, and performing Undercount and Overcount checks for interval readings.

•

Device Identifier : Device identifier checks validate that the device identifier provided with the measurement is valid. Device identifiers can include serial number, badge number, channel ID, etc.

•

Undercount : An undercount occurs when an interval initial measurement contains fewer interval values than approrpriate based on the interval size (or seconds-per-interval, or SPI) and the Start and End Date/Time values. For example, if an initial measurement has an interval size of one hour (or an SPI of 3600), and a Start Date/Time is October 27, 2011 and End Date/Time of October 28, 2011 (a total duration of 1 day), it should contain 24 interval values. If it contained less than 24 interval values, it could consitute an undercount.

•

Overcount : An overcount occurs when an interval initial measurement contains more interval values than approrpriate based on the interval size (or seconds-per-interval, or SPI) and the Start and End Date/Time values. For example, if an initial measurement has an interval size of one hour (or an SPI of 3600), and a Start Date/Time is October 27, 2011 and End Date/Time of October 28, 2011 (a total duration of 1 day), it should contain 24 interval values. If it contained more than 24 interval values, it could consitute an overcount.

If an incoming interval initial measurement contains either an invalid device identifier, an undercount, or an overcount, the measurement is rejected, and an instance of the IMD Seeder business object is created. Undercount and Overcount checks are performed by the "Perform Date/Time Adjustments and Undercount/Overcount Check" pre-processing algorithm (D1-DODTTMADJ).

Time Zone Translation

If your organization receives initial measurement from a source that provides its data in a different time zone than the one in which the data will be stored in Oracle Utilities Meter Data Management, a translation can be performed to translate the time zone from an external time zone identifier to one configured within the application. This translation is defined via the Head-End Time Zone to Standard Mapping extendable lookup.

Validation, Editing, and Estimation

Once received into the system, initial measurements are subject to validation, editing, and estimation. This process involves the following:

•

Validation : Validates that the initial measurement data is within expected tolerances, and is correct

•

Editing : If the initial measurement data is wrong in some way, the data can be automatically changed.

•

Estimation : If initial measurement data is incomplete (for example, if one or more interval values within an interval measurement are missing), missing values can be automatically estimated.

As noted above, the values recorded in an initial measurement can change during the validation, editing, and estimation processing, and exceptions can be raised if initial measurements are wrong in some way (such as out-of-tolerance quantities, incorrect values, etc.).

Note : The validation, editing, and estimation process is referred to as VEE, and is described in more detail in a later chapter.

Skipping VEE Processing - High Quality Check for Interval Initial Measurements

Execution of VEE rules is performed by an Enter algorithm on the "VEE Complete" state of the initial measurement business object. For interval initial measurements, the "High Quality Check - Vector Band Based" (D1-HIGHQUALV) algorithm can be used to skip VEE processing and transition the initial measurement directly to the "Finalized" state.

This algorithm checks whether the intervals within an initial measurement are considered to be of "high quality" (defined below), and if they are considered "high quality", the algorithm transitions the current initial measurement directly to the "Finalized" state.

An interval initial measurement is considered to be of "high quality" if the following conditions are met:

•

There are no missing intervals in the initial measurement

•

All interval values are within a range that extends above and below final interval values for the corresponding intervals from the previous reading. The range is defined by the "Low Tolerance" and "High Tolerance" algorithm parameters. These parameters define mutipliers that are applied to the corresponding interval from the previous reading. The "Low Tolerance" is subtracted from the previous reading’s final measurement, and the "High Tolerance" is added the the previous reading’s final measurement to define the range within which each interval must fall.

For example, if the previous reading’s final measurement value at 1:00 AM was 20, and the "Low Tolerance" parameter is set to 0.2 and the "High Tolerance" parameter is set to 0.25, the initial measurement’s value at 1:00 AM must be between between 16 (20 - 0.2*20) and 25 (20 + 0.25*20).

•

All intervals have a condition code that falls between the range defined by the "Default Bottom Range Condition Value" and "Default Top Range Condition Value" algorithm parameters.

If the initial measurement fails any part of the high quality assessment, the routine simply exits.

Pre VEE and Post VEE Quantities

Initial measurement data contains both the original and final versions of the quantities recorded by the measuring component.

•

Pre VEE quantities are consumption values derived from the measurements recorded by the head-end system or meter reader.

•

Post VEE quantities are the "final" values, after VEE processing.

Pre VEE and Post VEE quantities in an initial measurement often differ based on a number of conditions, including:

1.

The measuring component has a multiplier other than 1.

In this case, the Post VEE value is equal to the Pre VEE value times the multiplier.

2.

The installation event has a constant other than 1.

In this case, the Post VEE value is equal to the Pre VEE value times the installation constant.

3.

VEE rules have changed the quantities because they are missing or obviously wrong

In this, the Pre VEE values are adjusted based on the specifics of the VEE rules applied to the initial measurement to create the Post VEE values

4.

Manual changes by a user.

Condition Codes

In addition to recorded consumption values, measurements also have condition codes, used to indicate the source and quality of a measurement. For example:

•

Regularly recorded measurements might have a condition code of "Regular"

•

Missing measurements might have a condition code of "Missing"

•

Estimated measurements might have a condition code of "External Estimated" or "System Estimated" based on where the estimation was performed.

Both Pre VEE and Post VEE values have their own condition code, which can also change during VEE processing. For example, consider the following sample measurements from an interval measuring component:

Date / Time

Pre VEE Value

Pre VEE Condition

Post VEE Value

Post VEE Condition

01/01/2010 3:00 PM

14.678

Regular

15.1

Regular

01/01/2010 4:00 PM

Missing

20

Estimated

01/01/2010 5:00 PM

13.12

Regular

13.41

Regular

01/01/2010 6:00 PM

150.12

Regular

14.12

Estimated

For the 4:00 PM interval, note the Pre VEE condition indicates the interval is missing and the Post VEE condition highlights that it was estimated.

For the 6:00 PM interval (containing a spike, or an interval with conspicuously high usage relative to surrounding intervals), note that the system head-end (the system that recorded the measurement) indicated the interval value was fine (Pre VEE is regular), but the VEE process smoothed it, and set the Post VEE condition to "Estimated."

Condition Codes Extendable Lookup

Condition codes are defined in the Measurement Condition extendable lookup (D1-MeasurementConditionLookup). Base package condition codes delivered in this extendable lookup include the following:

Condition Code (Value)

Description

100000

No Read - System

101000

No Read - Outage

201000

Missing

301000

System Estimate

401000

External Estimate

402000

Office Estimate

501000

Regular

901000

Super

Additional condition codes can be added to this extendable lookup to meet requirements specific to individual implementations. Gaps between the base package condition code values allow custom condition codes to be added that represent data with conditions that fall between the base package conditions. For example, a condition code to indicate that the measurement was estimated based on partially incomplete data (and is considered to be of worse quality than "System Estimate", but better than "Missing") would fall somewhere between 201000 and 301000.

As a general rule, condition codes used to represent bad data or error conditions should be smaller than condition codes used to represent good data.’

Reader Remarks and Scalar Measurements

Initial measurements for manually-read scalar meters can create reader remarks. Reader remarks are a specific type of device event used to capture and/or record specific events or circumstances encountered when a meter reader is manually reading scalar meters.

Reader remark types are submitted with scalar initial measurements when received from a head-end system or meter read collection system. Reader remarks are NOT uploaded along with other device events. Reader remarks are ALWAYS associated with a scalar initial measurement.

Understanding Reader Remark Processing

This section provides an overview of the process that takes place when reader remarks are received within a scalar measurement. For each step in the process, the table below provides a brief description of the processing that takes place, and lists the specific objects used by the Service and Measurement Data Foundation

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

Step

Process

Service and Measurement Data Foundation Objects

1.

The system receives an initial measurement from a manually-read scalar device that contains one or more reader remark types.

The base package "Initial Load IMD (Scalar)" (D1-IntialLoadIMDScalar) business object supports inclusion of one or more reader remark types.

2.

When the initial measurement enters the Finalized state, an Enter algorithm creates a reader remark for each reader remark type included in the initial measurement.

Note: Creation of reader remarks does NOT make use of device event mapping extendable lookups.

Algorithm: D1-CRE-RR (Create Reader Remark)

3.

Reader remarks begin in the Pending state. They are transitioned to the Execute state either manually or via batch processing.

The Execute state contains a number of Enter algorithms that perform the following

•

Determine if the reader remark is eligible for processing, based on the "Eligible for Processing" flag on the reader remark type

•

Create a To Do Entry based on the "To Do Type" and "To Do Role" defined on the reader remark type

•

Create a service issue monitor based on the service issue monitor specified on the reader remark type

•

Send the reader remark to subscribing systems

Batch Control: D1-DVEVT (Device Event MO Periodic Monitor Process)

Algorithm: D1-RR-ELIG (Reader Remark Eligibility)

Algorithm: D1-CRE-RR-TD (Create To Do Entry for Reader Remark)

Algorithm: D1-DVCEVTSIM (Create Service Issue Monitor for Reader Remark)

Algorithm: D1-RRSENDSUB (Send to Subscribers for Reader Remark)

Sending Reader Remarks to Subscribing Systems

Reader remarks can be passed onto to other subscribing systems such as a customer information system (such as Oracle Utilities Customer Care and Billing), an outage system (such as Oracle Utilities Network Management System), or some other application.

Reader remarks are sent to subscribing systems when they enter the Execute state. An Enter algorithm (D1-RRSENDSUB /Send to Subscribers for Reader Remark in the base package) determines which service providers (external systems) are interested in receiving the current reader remark based upon its type and category, finds the processing method for each, and processes the device event accordingly.

The means of sending reader remark information to subscribing systems is defined in the "How to Send Device Event Related Information" processing method for the service provider representing the subscribing system. Reader remark information can be sent via outbound communication business object, outbound communication, or batch process.

The method for sending device events to subscribing systems (business object, outbound message, or batch process) is defined for the "Reader Remark" device event category, and can be overridden for individual reader remark types (including the ability to exclude specific reader remark types. In addition, a default event processing method can be also be configured that applies when methods of transmission aren't specified at the individual category level.

The "Subscribe to Device Event" business service is used to process reader remark subscription requests, and allow external applications to manage the categories of events they receive.

Reader Remarks and Service Issue Monitors

Like other device events, reader remarks can create service issue monitors. See Service Issue Monitors and Service Investigative Orders in Chapter 8: Device Communication and Device Events for more information about service issue monitors.

Subtractive Measuring Components

Initial measurement data for subtractive measuring components (such as most scalar measuring components) also typically contain start and stop readings in addition to Pre and Post VEE usage. For example, a set of initial measurements for s subtractive scalar measuring component might look like the following:

Date / Time

Start Reading

Stop Reading

Pre VEE Usage

Pre VEE Condition

Post VEE Value

Post VEE Usage

01/01/2010 3:00 PM

0

1500

1500

Regular

1515

Regular

02/2/2010 4:11 PM

1500

2100

600

Regular

606

Regular

03/03/2010 5:22 PM

2100

2900

800

Regular

808

Regular

04/01/2010 1:00 PM

2900

3500

600

Regular

606

Regular

Rollover Calculations

Subtractive measuring components can "rollover" when the reading exceeds the maximum value based on the number of dials. For example, a register with a 4 dials can record values up to 9999 before rolling over to 0000. When this occurs, consumption is calculated based on the following attributes and calculated values.

•

Rollover Threshold is the percentage of the measuring component's dial capacity at which measurements for measuring components of this type are considered to have rolled over. Dial capacity is the largest value that can be recorded for the measuring component, based on the measuring component's number of dials. For example, a measuring component with 5 dials has a dial capacity of 99999.

•

MaxDialCapacity is the maximum value for the number of dials, rounded up to the next whole multiple of 10 (or 10 raised to the power of the number of dials). For example, for a register with 4 dials, the MaxDialValue is 10000.

•

MaxAcceptableDifference is the maximum acceptable consumption that can be recorded for the register. This is equal to the MaxDialCapacity multiplied by the rollover threshold. For example, the MaxAcceptableDifference for a register with 4 dials and a rollover threshold of 90% would be 9000. If the consumption is greater than this value, the initial measurement is transitioned to the Error state.

•

Difference : The difference between the Stop Reading and Start Reading, obtained by subtracting the Start Reading from the Stop Reading. If the Difference is less than zero (<0), then add the MaxDialCapacity to calculate Rollover.

•

Rollover : The adjusted consumption for a reading on a register that has rolled over. Only applicable if the Difference (Stop Reading - Start Reading) is less than zero (<0).

•

Consumption : The calculated consumption for the reading, equal to either the Difference or Rollover. If the Difference is greater than or equal to zero, consumption is equal to the Difference. If the Difference is less than zero (<0), and the Rollover is less than or equal to the MaxAcceptableDifference, the consumption is equal to the Rollover.

Example : Consider an initial measurement with the following attributes:

•

Number of Dials: 4

•

Rollover Threshold: 90 (%)

•

Start Reading: 8900

•

Stop Reading: 0500

For this reading,

MaxDialCapacity = 10000

MaxAcceptableDifference = 9000 (10000 * .90)

Difference = 0500 (Stop Reading) - 8900 (Start Reading) or -8400

Rollover = 10000 (MaxDialCapacity) + -8400 (Difference) or 1600

Consumption is equal to 1600 (Rollover).

Estimated Initial Measurements

Over the course of time, it may happen that the system will not receive usage for a device for some period of time. When the system detects that a measuring component is missing final measurements, it can creates a initial measurement via estimation. This type of initial measurement is referred to as an estimated initial measurement (as opposed to an Initial Load or Manual initial measurement).

At a high-level, the estimation process is as follows:

•

Missing Measurements are detected by a "Period Estimation" system event algorithm on the measuring component business object

•

Estimated initial measurements are created for the "missing" time period by the "Period Estimation" system event algorithm on the measuring component business object

•

Values and consumption for the estimated initial measurements are calculated by "estimation" VEE rules.

It’s important to note that the processes that detect missing measurements do NOT themselves estimate consumption. Rather, these detection processes simply create an initial measurement and let the estimation VEE rules estimate the consumption for the initial measurement.

Detecting Missing Measurements

The detection of missing measurements occurs at different points in time for interval and scalar measuring components:

•

For interval measuring components, a dedicated batch process exists to initiate creation of estimated initial measurements

•

For manually read scalar measuring components, a usage calculation rule creates the initial measurement if it cannot find a measurement and it has been given permission to estimate. (Note: the information that follows applies primarily to interval measuring components).

The batch process that detects missing consumption for interval measuring components uses two elements on interval measurinng component type:

•

Hours Before Estimation : the number of hours after the End Date and Time of the most recent measurement that must pass before the measuring component is considered due for estimation. For example, if set to 72 hours, estimation will only take place 72 hours after the End Date and Time of the latest measurement.

•

Number of Hours to Estimate : the number of hours of measurement data that are estimated when estimation is performed for the measuring component.

If a measuring component has contiguous final measurements on/after a date and time equal to the current date/time minus the "Hours Before Estimate" value, the measuring component is not estimated.

If the measuring component does NOT have contiguous final measurements on/after a date and time equal to the current date/time minus the "Hours Before Estimate" value, the measuring component is estimated. If the measuring component is subject to estimation, measurements will be estimated through the a date and time equal to the current date/time minus the (Hours Before Estimation - Number of Hours to Estimate).

The following examples illustrate how the system determines if estimation should take place. These examples are all assume a measuring component whose measuring component type specifies an "Hours Before Estimation" of 72 (3 days) and a "Number of Hours to Estimate" of 24 (1 day).

Example 1 : On January 9, if there is contiguous consumption through January 7, estimation would not occur because consumption exists after January 6 (3 days prior to January 9). The diagram below illustrates this example:

Example 2 : On Janury 9 if contiguous consumption existed through January 2, estimation would take place because consumption does not exist through January 6 (3 days prior to January 9). In this example, consumption would be estimated for missing intervals from January 2 through January 7 (January 9 minus 48 hours (Hours Before Estimation minus Number of Hours to Estimate). Note that this assumes that period estimation had NOT been run after January 5. The diagram below illustrates this example:

Example 3 : On Janury 9 if contiguous consumption existed through January 2 and for January 5 (but NOT for January 3-4 or 6-7), two initial measurements would be created, one for January 3-4, and another for January 6-7. The diagram below illustrates this example:

Estimation Algorithms

Estimation for interval measuring components is detected and initiated by two algorithms, one on the device business object, and the other on the measuring component business object.

Devices whose measuring components are subject to periodic estimation (in most cases, interval measuring components) have a "Period Estimation" Monitor algorithm (D1-PERESTM) on their Active state. This monitoring algorithm retrieves the device's measuring component and invokes the algorithm on the "Periodic Estimation" system event on the measuring component business object. Note - the device monitoring algorithm can be configured to look at device configurations from a number of days in the past defined by an algorithm parameter. The base package includes this algorithm on the Active state of the Smart Meter (D1-SmartMeter) device business object. The "Periodic Estimation" monitor algorithm can be triggered by the "Smart Meter State Monitor Process" batch process (D1-SMMTR).

The "Periodic Estimation" System Event algorithm determines if a measuring component is missing final measurements (as described above), and if final measurements are missing, estimates initial measurements and/or creates a To Do Entry. In the base package, this algorithm is the "Create Initial Measurement and To Do Entry" algorithm (D1-CRIMTODO). Algorithm parameters can specify if an initial measurement is to be created, if an To Do Entry is to be created, and the To Do Type and Role (if applicable) for any To Do entries created. The base package includes this algorithm on the Period Estimation system event state of the Interval Channel (D1-IntervalChannel) measuring component business object.

Estimation Calculations

When new estimated initial measurements are created (for either interval or scalar measuring components), the Pre-VEE and Post-VEE values are initially set to zero. When the initial measurement enters the "VEE Complete" state, the VEE rules within the VEE group defined for the "Estimation" VEE role (defined by the "VEE Group For Estimation" field on the measuring component) calculate values and consumption for the initial measurement.

Note that the VEE rules used in this process can also include validation rules that perform validation on the estimated values and consumption. For example, the "estimation" VEE group might contain rules to estimate interval values from a profile, and then perform a sum check to validate the resulting interval measurement against measurements from a consumption reference measuring component. In this example, the sum check validation would be configured to be applied after the interval profile estimation.

Estimated initial measurements are created using "estimation" initial measurement business objects. The base package includes the Estimation IMD (Interval) and Estimation IMD (Scalar) business objects (D1-EstimationIMDInterval or D1-EstimationIMDScalar, respectively).

Initial Measurement Data

Measurements read from a measuring component are referred to as "initial measurement data" (or initial measurements) and are used to record how much of the quantity (defined by UOM, TOU, and SQI) measured by the measuring component was consumed.

Initial measurement data for scalar measuring components contain a single "reading" or value, while initial measurement data for interval measuring components can contain multiple readings, one for each interval that falls between the start time and stop time of the measurement.

At a simple level, initial measurement data goes through the following process:

1.

Initial measurements are loaded into the system.

2.

Initial measurement data is validated, edited, and estimated.

3.

Initial measurements are converted into final measurements.

4.

Final measurements are used to calculate usage (bill determinants, etc.).

Creating Initial Measurements

The IMD Seeder business object (D1-IMDSeeder) is used to create initial measurements (via instantiating initial measurement business objects), based on the head-end system sending the measurement. The "Initial Measurement Creation" processing method defined for the head-end system service provider defines the specific type of initial measurement to create. If for some reason an initial measurement can’t be created, an instance of the IMD Seeder business object is created to allow tracking of the error (and once the error is resolved, the IMD Seeder instance can be reprocessed.

The IMD Seeder business object determines the service provider and measuring component for the measurement (based on attributes supplied in the incoming reading, such as device ID, external reference ID, etc.). This is performed by the "Derive Service Provider and Measuring Component" pre-processing algorithm (D1-DER-SPRMC).

If the service provider is not specified on the device, the algorithm tries to derive it from the device type. Otherwise, it attempts to derive the service provider from the measurement cycle route from the service point at which the device is installed (if available).

The IMD Seeder also ensures that the Start and End Date/Time fields on the initial measurement are populated, deriving them from the incoming reading if necessary. This step is performed by the "Derive IMD Date/Time Values" pre-processing algorithm (D1-VALDR-INP).

Critical Validations

The IMD Seeder also performs a series of critical validations to ensure that the incokming reading contains valid data. These critical validations include validating that the device identifier supplied is valid and exists in the system, and performing Undercount and Overcount checks for interval readings.

•

Device Identifier : Device identifier checks validate that the device identifier provided with the measurement is valid. Device identifiers can include serial number, badge number, channel ID, etc.

•

Undercount : An undercount occurs when an interval initial measurement contains fewer interval values than approrpriate based on the interval size (or seconds-per-interval, or SPI) and the Start and End Date/Time values. For example, if an initial measurement has an interval size of one hour (or an SPI of 3600), and a Start Date/Time is October 27, 2011 and End Date/Time of October 28, 2011 (a total duration of 1 day), it should contain 24 interval values. If it contained less than 24 interval values, it could consitute an undercount.

•

Overcount : An overcount occurs when an interval initial measurement contains more interval values than approrpriate based on the interval size (or seconds-per-interval, or SPI) and the Start and End Date/Time values. For example, if an initial measurement has an interval size of one hour (or an SPI of 3600), and a Start Date/Time is October 27, 2011 and End Date/Time of October 28, 2011 (a total duration of 1 day), it should contain 24 interval values. If it contained more than 24 interval values, it could consitute an overcount.

If an incoming interval initial measurement contains either an invalid device identifier, an undercount, or an overcount, the measurement is rejected, and an instance of the IMD Seeder business object is created. Undercount and Overcount checks are performed by the "Perform Date/Time Adjustments and Undercount/Overcount Check" pre-processing algorithm (D1-DODTTMADJ).

Time Zone Translation

If your organization receives initial measurement from a source that provides its data in a different time zone than the one in which the data will be stored in Oracle Utilities Meter Data Management, a translation can be performed to translate the time zone from an external time zone identifier to one configured within the application. This translation is defined via the Head-End Time Zone to Standard Mapping extendable lookup.

Validation, Editing, and Estimation

Once received into the system, initial measurements are subject to validation, editing, and estimation. This process involves the following:

•

Validation : Validates that the initial measurement data is within expected tolerances, and is correct

•

Editing : If the initial measurement data is wrong in some way, the data can be automatically changed.

•

Estimation : If initial measurement data is incomplete (for example, if one or more interval values within an interval measurement are missing), missing values can be automatically estimated.

As noted above, the values recorded in an initial measurement can change during the validation, editing, and estimation processing, and exceptions can be raised if initial measurements are wrong in some way (such as out-of-tolerance quantities, incorrect values, etc.).

Note : The validation, editing, and estimation process is referred to as VEE, and is described in more detail in a later chapter.

Skipping VEE Processing - High Quality Check for Interval Initial Measurements

Execution of VEE rules is performed by an Enter algorithm on the "VEE Complete" state of the initial measurement business object. For interval initial measurements, the "High Quality Check - Vector Band Based" (D1-HIGHQUALV) algorithm can be used to skip VEE processing and transition the initial measurement directly to the "Finalized" state.

This algorithm checks whether the intervals within an initial measurement are considered to be of "high quality" (defined below), and if they are considered "high quality", the algorithm transitions the current initial measurement directly to the "Finalized" state.

An interval initial measurement is considered to be of "high quality" if the following conditions are met:

•

There are no missing intervals in the initial measurement

•

All interval values are within a range that extends above and below final interval values for the corresponding intervals from the previous reading. The range is defined by the "Low Tolerance" and "High Tolerance" algorithm parameters. These parameters define mutipliers that are applied to the corresponding interval from the previous reading. The "Low Tolerance" is subtracted from the previous reading’s final measurement, and the "High Tolerance" is added the the previous reading’s final measurement to define the range within which each interval must fall.

For example, if the previous reading’s final measurement value at 1:00 AM was 20, and the "Low Tolerance" parameter is set to 0.2 and the "High Tolerance" parameter is set to 0.25, the initial measurement’s value at 1:00 AM must be between between 16 (20 - 0.2*20) and 25 (20 + 0.25*20).

•

All intervals have a condition code that falls between the range defined by the "Default Bottom Range Condition Value" and "Default Top Range Condition Value" algorithm parameters.

If the initial measurement fails any part of the high quality assessment, the routine simply exits.

Pre VEE and Post VEE Quantities

Initial measurement data contains both the original and final versions of the quantities recorded by the measuring component.

•

Pre VEE quantities are consumption values derived from the measurements recorded by the head-end system or meter reader.

•

Post VEE quantities are the "final" values, after VEE processing.

Pre VEE and Post VEE quantities in an initial measurement often differ based on a number of conditions, including:

1.

The measuring component has a multiplier other than 1.

In this case, the Post VEE value is equal to the Pre VEE value times the multiplier.

2.

The installation event has a constant other than 1.

In this case, the Post VEE value is equal to the Pre VEE value times the installation constant.

3.

VEE rules have changed the quantities because they are missing or obviously wrong

In this, the Pre VEE values are adjusted based on the specifics of the VEE rules applied to the initial measurement to create the Post VEE values

4.

Manual changes by a user.

Condition Codes

In addition to recorded consumption values, measurements also have condition codes, used to indicate the source and quality of a measurement. For example:

•

Regularly recorded measurements might have a condition code of "Regular"

•

Missing measurements might have a condition code of "Missing"

•

Estimated measurements might have a condition code of "External Estimated" or "System Estimated" based on where the estimation was performed.

Both Pre VEE and Post VEE values have their own condition code, which can also change during VEE processing. For example, consider the following sample measurements from an interval measuring component:

Date / Time

Pre VEE Value

Pre VEE Condition

Post VEE Value

Post VEE Condition

01/01/2010 3:00 PM

14.678

Regular

15.1

Regular

01/01/2010 4:00 PM

Missing

20

Estimated

01/01/2010 5:00 PM

13.12

Regular

13.41

Regular

01/01/2010 6:00 PM

150.12

Regular

14.12

Estimated

For the 4:00 PM interval, note the Pre VEE condition indicates the interval is missing and the Post VEE condition highlights that it was estimated.

For the 6:00 PM interval (containing a spike, or an interval with conspicuously high usage relative to surrounding intervals), note that the system head-end (the system that recorded the measurement) indicated the interval value was fine (Pre VEE is regular), but the VEE process smoothed it, and set the Post VEE condition to "Estimated."

Condition Codes Extendable Lookup

Condition codes are defined in the Measurement Condition extendable lookup (D1-MeasurementConditionLookup). Base package condition codes delivered in this extendable lookup include the following:

Condition Code (Value)

Description

100000

No Read - System

101000

No Read - Outage

201000

Missing

301000

System Estimate

401000

External Estimate

402000

Office Estimate

501000

Regular

901000

Super

Additional condition codes can be added to this extendable lookup to meet requirements specific to individual implementations. Gaps between the base package condition code values allow custom condition codes to be added that represent data with conditions that fall between the base package conditions. For example, a condition code to indicate that the measurement was estimated based on partially incomplete data (and is considered to be of worse quality than "System Estimate", but better than "Missing") would fall somewhere between 201000 and 301000.

As a general rule, condition codes used to represent bad data or error conditions should be smaller than condition codes used to represent good data.’

Reader Remarks and Scalar Measurements

Initial measurements for manually-read scalar meters can create reader remarks. Reader remarks are a specific type of device event used to capture and/or record specific events or circumstances encountered when a meter reader is manually reading scalar meters.

Reader remark types are submitted with scalar initial measurements when received from a head-end system or meter read collection system. Reader remarks are NOT uploaded along with other device events. Reader remarks are ALWAYS associated with a scalar initial measurement.

Understanding Reader Remark Processing

This section provides an overview of the process that takes place when reader remarks are received within a scalar measurement. For each step in the process, the table below provides a brief description of the processing that takes place, and lists the specific objects used by the Service and Measurement Data Foundation

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

Step

Process

Service and Measurement Data Foundation Objects

1.

The system receives an initial measurement from a manually-read scalar device that contains one or more reader remark types.

The base package "Initial Load IMD (Scalar)" (D1-IntialLoadIMDScalar) business object supports inclusion of one or more reader remark types.

2.

When the initial measurement enters the Finalized state, an Enter algorithm creates a reader remark for each reader remark type included in the initial measurement.

Note: Creation of reader remarks does NOT make use of device event mapping extendable lookups.

Algorithm: D1-CRE-RR (Create Reader Remark)

3.

Reader remarks begin in the Pending state. They are transitioned to the Execute state either manually or via batch processing.

The Execute state contains a number of Enter algorithms that perform the following

•

Determine if the reader remark is eligible for processing, based on the "Eligible for Processing" flag on the reader remark type

•

Create a To Do Entry based on the "To Do Type" and "To Do Role" defined on the reader remark type

•

Create a service issue monitor based on the service issue monitor specified on the reader remark type

•

Send the reader remark to subscribing systems

Batch Control: D1-DVEVT (Device Event MO Periodic Monitor Process)

Algorithm: D1-RR-ELIG (Reader Remark Eligibility)

Algorithm: D1-CRE-RR-TD (Create To Do Entry for Reader Remark)

Algorithm: D1-DVCEVTSIM (Create Service Issue Monitor for Reader Remark)

Algorithm: D1-RRSENDSUB (Send to Subscribers for Reader Remark)

Sending Reader Remarks to Subscribing Systems

Reader remarks can be passed onto to other subscribing systems such as a customer information system (such as Oracle Utilities Customer Care and Billing), an outage system (such as Oracle Utilities Network Management System), or some other application.

Reader remarks are sent to subscribing systems when they enter the Execute state. An Enter algorithm (D1-RRSENDSUB /Send to Subscribers for Reader Remark in the base package) determines which service providers (external systems) are interested in receiving the current reader remark based upon its type and category, finds the processing method for each, and processes the device event accordingly.

The means of sending reader remark information to subscribing systems is defined in the "How to Send Device Event Related Information" processing method for the service provider representing the subscribing system. Reader remark information can be sent via outbound communication business object, outbound communication, or batch process.

The method for sending device events to subscribing systems (business object, outbound message, or batch process) is defined for the "Reader Remark" device event category, and can be overridden for individual reader remark types (including the ability to exclude specific reader remark types. In addition, a default event processing method can be also be configured that applies when methods of transmission aren't specified at the individual category level.

The "Subscribe to Device Event" business service is used to process reader remark subscription requests, and allow external applications to manage the categories of events they receive.

Reader Remarks and Service Issue Monitors

Like other device events, reader remarks can create service issue monitors. See Service Issue Monitors and Service Investigative Orders in Chapter 8: Device Communication and Device Events for more information about service issue monitors.

Subtractive Measuring Components

Initial measurement data for subtractive measuring components (such as most scalar measuring components) also typically contain start and stop readings in addition to Pre and Post VEE usage. For example, a set of initial measurements for s subtractive scalar measuring component might look like the following:

Date / Time

Start Reading

Stop Reading

Pre VEE Usage

Pre VEE Condition

Post VEE Value

Post VEE Usage

01/01/2010 3:00 PM

0

1500

1500

Regular

1515

Regular

02/2/2010 4:11 PM

1500

2100

600

Regular

606

Regular

03/03/2010 5:22 PM

2100

2900

800

Regular

808

Regular

04/01/2010 1:00 PM

2900

3500

600

Regular

606

Regular

Rollover Calculations

Subtractive measuring components can "rollover" when the reading exceeds the maximum value based on the number of dials. For example, a register with a 4 dials can record values up to 9999 before rolling over to 0000. When this occurs, consumption is calculated based on the following attributes and calculated values.

•

Rollover Threshold is the percentage of the measuring component's dial capacity at which measurements for measuring components of this type are considered to have rolled over. Dial capacity is the largest value that can be recorded for the measuring component, based on the measuring component's number of dials. For example, a measuring component with 5 dials has a dial capacity of 99999.

•

MaxDialCapacity is the maximum value for the number of dials, rounded up to the next whole multiple of 10 (or 10 raised to the power of the number of dials). For example, for a register with 4 dials, the MaxDialValue is 10000.

•

MaxAcceptableDifference is the maximum acceptable consumption that can be recorded for the register. This is equal to the MaxDialCapacity multiplied by the rollover threshold. For example, the MaxAcceptableDifference for a register with 4 dials and a rollover threshold of 90% would be 9000. If the consumption is greater than this value, the initial measurement is transitioned to the Error state.

•

Difference : The difference between the Stop Reading and Start Reading, obtained by subtracting the Start Reading from the Stop Reading. If the Difference is less than zero (<0), then add the MaxDialCapacity to calculate Rollover.

•

Rollover : The adjusted consumption for a reading on a register that has rolled over. Only applicable if the Difference (Stop Reading - Start Reading) is less than zero (<0).

•

Consumption : The calculated consumption for the reading, equal to either the Difference or Rollover. If the Difference is greater than or equal to zero, consumption is equal to the Difference. If the Difference is less than zero (<0), and the Rollover is less than or equal to the MaxAcceptableDifference, the consumption is equal to the Rollover.

Example : Consider an initial measurement with the following attributes:

•

Number of Dials: 4

•

Rollover Threshold: 90 (%)

•

Start Reading: 8900

•

Stop Reading: 0500

For this reading,

MaxDialCapacity = 10000

MaxAcceptableDifference = 9000 (10000 * .90)

Difference = 0500 (Stop Reading) - 8900 (Start Reading) or -8400

Rollover = 10000 (MaxDialCapacity) + -8400 (Difference) or 1600

Consumption is equal to 1600 (Rollover).

Estimated Initial Measurements

Over the course of time, it may happen that the system will not receive usage for a device for some period of time. When the system detects that a measuring component is missing final measurements, it can creates a initial measurement via estimation. This type of initial measurement is referred to as an estimated initial measurement (as opposed to an Initial Load or Manual initial measurement).

At a high-level, the estimation process is as follows:

•

Missing Measurements are detected by a "Period Estimation" system event algorithm on the measuring component business object

•

Estimated initial measurements are created for the "missing" time period by the "Period Estimation" system event algorithm on the measuring component business object

•

Values and consumption for the estimated initial measurements are calculated by "estimation" VEE rules.

It’s important to note that the processes that detect missing measurements do NOT themselves estimate consumption. Rather, these detection processes simply create an initial measurement and let the estimation VEE rules estimate the consumption for the initial measurement.

Detecting Missing Measurements

The detection of missing measurements occurs at different points in time for interval and scalar measuring components:

•

For interval measuring components, a dedicated batch process exists to initiate creation of estimated initial measurements

•

For manually read scalar measuring components, a usage calculation rule creates the initial measurement if it cannot find a measurement and it has been given permission to estimate. (Note: the information that follows applies primarily to interval measuring components).

The batch process that detects missing consumption for interval measuring components uses two elements on interval measurinng component type:

•

Hours Before Estimation : the number of hours after the End Date and Time of the most recent measurement that must pass before the measuring component is considered due for estimation. For example, if set to 72 hours, estimation will only take place 72 hours after the End Date and Time of the latest measurement.

•

Number of Hours to Estimate : the number of hours of measurement data that are estimated when estimation is performed for the measuring component.

If a measuring component has contiguous final measurements on/after a date and time equal to the current date/time minus the "Hours Before Estimate" value, the measuring component is not estimated.

If the measuring component does NOT have contiguous final measurements on/after a date and time equal to the current date/time minus the "Hours Before Estimate" value, the measuring component is estimated. If the measuring component is subject to estimation, measurements will be estimated through the a date and time equal to the current date/time minus the (Hours Before Estimation - Number of Hours to Estimate).

The following examples illustrate how the system determines if estimation should take place. These examples are all assume a measuring component whose measuring component type specifies an "Hours Before Estimation" of 72 (3 days) and a "Number of Hours to Estimate" of 24 (1 day).

Example 1 : On January 9, if there is contiguous consumption through January 7, estimation would not occur because consumption exists after January 6 (3 days prior to January 9). The diagram below illustrates this example:

Example 2 : On Janury 9 if contiguous consumption existed through January 2, estimation would take place because consumption does not exist through January 6 (3 days prior to January 9). In this example, consumption would be estimated for missing intervals from January 2 through January 7 (January 9 minus 48 hours (Hours Before Estimation minus Number of Hours to Estimate). Note that this assumes that period estimation had NOT been run after January 5. The diagram below illustrates this example:

Example 3 : On Janury 9 if contiguous consumption existed through January 2 and for January 5 (but NOT for January 3-4 or 6-7), two initial measurements would be created, one for January 3-4, and another for January 6-7. The diagram below illustrates this example:

Estimation Algorithms

Estimation for interval measuring components is detected and initiated by two algorithms, one on the device business object, and the other on the measuring component business object.

Devices whose measuring components are subject to periodic estimation (in most cases, interval measuring components) have a "Period Estimation" Monitor algorithm (D1-PERESTM) on their Active state. This monitoring algorithm retrieves the device's measuring component and invokes the algorithm on the "Periodic Estimation" system event on the measuring component business object. Note - the device monitoring algorithm can be configured to look at device configurations from a number of days in the past defined by an algorithm parameter. The base package includes this algorithm on the Active state of the Smart Meter (D1-SmartMeter) device business object. The "Periodic Estimation" monitor algorithm can be triggered by the "Smart Meter State Monitor Process" batch process (D1-SMMTR).

The "Periodic Estimation" System Event algorithm determines if a measuring component is missing final measurements (as described above), and if final measurements are missing, estimates initial measurements and/or creates a To Do Entry. In the base package, this algorithm is the "Create Initial Measurement and To Do Entry" algorithm (D1-CRIMTODO). Algorithm parameters can specify if an initial measurement is to be created, if an To Do Entry is to be created, and the To Do Type and Role (if applicable) for any To Do entries created. The base package includes this algorithm on the Period Estimation system event state of the Interval Channel (D1-IntervalChannel) measuring component business object.

Estimation Calculations

When new estimated initial measurements are created (for either interval or scalar measuring components), the Pre-VEE and Post-VEE values are initially set to zero. When the initial measurement enters the "VEE Complete" state, the VEE rules within the VEE group defined for the "Estimation" VEE role (defined by the "VEE Group For Estimation" field on the measuring component) calculate values and consumption for the initial measurement.

Note that the VEE rules used in this process can also include validation rules that perform validation on the estimated values and consumption. For example, the "estimation" VEE group might contain rules to estimate interval values from a profile, and then perform a sum check to validate the resulting interval measurement against measurements from a consumption reference measuring component. In this example, the sum check validation would be configured to be applied after the interval profile estimation.

Estimated initial measurements are created using "estimation" initial measurement business objects. The base package includes the Estimation IMD (Interval) and Estimation IMD (Scalar) business objects (D1-EstimationIMDInterval or D1-EstimationIMDScalar, respectively).

Initial Measurement Data

Measurements read from a measuring component are referred to as "initial measurement data" (or initial measurements) and are used to record how much of the quantity (defined by UOM, TOU, and SQI) measured by the measuring component was consumed.

Initial measurement data for scalar measuring components contain a single "reading" or value, while initial measurement data for interval measuring components can contain multiple readings, one for each interval that falls between the start time and stop time of the measurement.

At a simple level, initial measurement data goes through the following process:

1.

Initial measurements are loaded into the system.

2.

Initial measurement data is validated, edited, and estimated.

3.

Initial measurements are converted into final measurements.

4.

Final measurements are used to calculate usage (bill determinants, etc.).

Creating Initial Measurements

The IMD Seeder business object (D1-IMDSeeder) is used to create initial measurements (via instantiating initial measurement business objects), based on the head-end system sending the measurement. The "Initial Measurement Creation" processing method defined for the head-end system service provider defines the specific type of initial measurement to create. If for some reason an initial measurement can’t be created, an instance of the IMD Seeder business object is created to allow tracking of the error (and once the error is resolved, the IMD Seeder instance can be reprocessed.

The IMD Seeder business object determines the service provider and measuring component for the measurement (based on attributes supplied in the incoming reading, such as device ID, external reference ID, etc.). This is performed by the "Derive Service Provider and Measuring Component" pre-processing algorithm (D1-DER-SPRMC).

If the service provider is not specified on the device, the algorithm tries to derive it from the device type. Otherwise, it attempts to derive the service provider from the measurement cycle route from the service point at which the device is installed (if available).

The IMD Seeder also ensures that the Start and End Date/Time fields on the initial measurement are populated, deriving them from the incoming reading if necessary. This step is performed by the "Derive IMD Date/Time Values" pre-processing algorithm (D1-VALDR-INP).

Critical Validations

The IMD Seeder also performs a series of critical validations to ensure that the incokming reading contains valid data. These critical validations include validating that the device identifier supplied is valid and exists in the system, and performing Undercount and Overcount checks for interval readings.

•

Device Identifier : Device identifier checks validate that the device identifier provided with the measurement is valid. Device identifiers can include serial number, badge number, channel ID, etc.

•

Undercount : An undercount occurs when an interval initial measurement contains fewer interval values than approrpriate based on the interval size (or seconds-per-interval, or SPI) and the Start and End Date/Time values. For example, if an initial measurement has an interval size of one hour (or an SPI of 3600), and a Start Date/Time is October 27, 2011 and End Date/Time of October 28, 2011 (a total duration of 1 day), it should contain 24 interval values. If it contained less than 24 interval values, it could consitute an undercount.

•

Overcount : An overcount occurs when an interval initial measurement contains more interval values than approrpriate based on the interval size (or seconds-per-interval, or SPI) and the Start and End Date/Time values. For example, if an initial measurement has an interval size of one hour (or an SPI of 3600), and a Start Date/Time is October 27, 2011 and End Date/Time of October 28, 2011 (a total duration of 1 day), it should contain 24 interval values. If it contained more than 24 interval values, it could consitute an overcount.

If an incoming interval initial measurement contains either an invalid device identifier, an undercount, or an overcount, the measurement is rejected, and an instance of the IMD Seeder business object is created. Undercount and Overcount checks are performed by the "Perform Date/Time Adjustments and Undercount/Overcount Check" pre-processing algorithm (D1-DODTTMADJ).

Time Zone Translation

If your organization receives initial measurement from a source that provides its data in a different time zone than the one in which the data will be stored in Oracle Utilities Meter Data Management, a translation can be performed to translate the time zone from an external time zone identifier to one configured within the application. This translation is defined via the Head-End Time Zone to Standard Mapping extendable lookup.

Validation, Editing, and Estimation

Once received into the system, initial measurements are subject to validation, editing, and estimation. This process involves the following:

•

Validation : Validates that the initial measurement data is within expected tolerances, and is correct

•

Editing : If the initial measurement data is wrong in some way, the data can be automatically changed.

•

Estimation : If initial measurement data is incomplete (for example, if one or more interval values within an interval measurement are missing), missing values can be automatically estimated.

As noted above, the values recorded in an initial measurement can change during the validation, editing, and estimation processing, and exceptions can be raised if initial measurements are wrong in some way (such as out-of-tolerance quantities, incorrect values, etc.).

Note : The validation, editing, and estimation process is referred to as VEE, and is described in more detail in a later chapter.

Skipping VEE Processing - High Quality Check for Interval Initial Measurements

Execution of VEE rules is performed by an Enter algorithm on the "VEE Complete" state of the initial measurement business object. For interval initial measurements, the "High Quality Check - Vector Band Based" (D1-HIGHQUALV) algorithm can be used to skip VEE processing and transition the initial measurement directly to the "Finalized" state.

This algorithm checks whether the intervals within an initial measurement are considered to be of "high quality" (defined below), and if they are considered "high quality", the algorithm transitions the current initial measurement directly to the "Finalized" state.

An interval initial measurement is considered to be of "high quality" if the following conditions are met:

•

There are no missing intervals in the initial measurement

•

All interval values are within a range that extends above and below final interval values for the corresponding intervals from the previous reading. The range is defined by the "Low Tolerance" and "High Tolerance" algorithm parameters. These parameters define mutipliers that are applied to the corresponding interval from the previous reading. The "Low Tolerance" is subtracted from the previous reading’s final measurement, and the "High Tolerance" is added the the previous reading’s final measurement to define the range within which each interval must fall.

For example, if the previous reading’s final measurement value at 1:00 AM was 20, and the "Low Tolerance" parameter is set to 0.2 and the "High Tolerance" parameter is set to 0.25, the initial measurement’s value at 1:00 AM must be between between 16 (20 - 0.2*20) and 25 (20 + 0.25*20).

•

All intervals have a condition code that falls between the range defined by the "Default Bottom Range Condition Value" and "Default Top Range Condition Value" algorithm parameters.

If the initial measurement fails any part of the high quality assessment, the routine simply exits.

Pre VEE and Post VEE Quantities

Initial measurement data contains both the original and final versions of the quantities recorded by the measuring component.

•

Pre VEE quantities are consumption values derived from the measurements recorded by the head-end system or meter reader.

•

Post VEE quantities are the "final" values, after VEE processing.

Pre VEE and Post VEE quantities in an initial measurement often differ based on a number of conditions, including:

1.

The measuring component has a multiplier other than 1.

In this case, the Post VEE value is equal to the Pre VEE value times the multiplier.

2.

The installation event has a constant other than 1.

In this case, the Post VEE value is equal to the Pre VEE value times the installation constant.

3.

VEE rules have changed the quantities because they are missing or obviously wrong

In this, the Pre VEE values are adjusted based on the specifics of the VEE rules applied to the initial measurement to create the Post VEE values

4.

Manual changes by a user.

Condition Codes

In addition to recorded consumption values, measurements also have condition codes, used to indicate the source and quality of a measurement. For example:

•

Regularly recorded measurements might have a condition code of "Regular"

•

Missing measurements might have a condition code of "Missing"

•

Estimated measurements might have a condition code of "External Estimated" or "System Estimated" based on where the estimation was performed.

Both Pre VEE and Post VEE values have their own condition code, which can also change during VEE processing. For example, consider the following sample measurements from an interval measuring component:

Date / Time

Pre VEE Value

Pre VEE Condition

Post VEE Value

Post VEE Condition

01/01/2010 3:00 PM

14.678

Regular

15.1

Regular

01/01/2010 4:00 PM

Missing

20

Estimated

01/01/2010 5:00 PM

13.12

Regular

13.41

Regular

01/01/2010 6:00 PM

150.12

Regular

14.12

Estimated

For the 4:00 PM interval, note the Pre VEE condition indicates the interval is missing and the Post VEE condition highlights that it was estimated.

For the 6:00 PM interval (containing a spike, or an interval with conspicuously high usage relative to surrounding intervals), note that the system head-end (the system that recorded the measurement) indicated the interval value was fine (Pre VEE is regular), but the VEE process smoothed it, and set the Post VEE condition to "Estimated."

Condition Codes Extendable Lookup

Condition codes are defined in the Measurement Condition extendable lookup (D1-MeasurementConditionLookup). Base package condition codes delivered in this extendable lookup include the following:

Condition Code (Value)

Description

100000

No Read - System

101000

No Read - Outage

201000

Missing

301000

System Estimate

401000

External Estimate

402000

Office Estimate

501000

Regular

901000

Super

Additional condition codes can be added to this extendable lookup to meet requirements specific to individual implementations. Gaps between the base package condition code values allow custom condition codes to be added that represent data with conditions that fall between the base package conditions. For example, a condition code to indicate that the measurement was estimated based on partially incomplete data (and is considered to be of worse quality than "System Estimate", but better than "Missing") would fall somewhere between 201000 and 301000.

As a general rule, condition codes used to represent bad data or error conditions should be smaller than condition codes used to represent good data.’

Reader Remarks and Scalar Measurements

Initial measurements for manually-read scalar meters can create reader remarks. Reader remarks are a specific type of device event used to capture and/or record specific events or circumstances encountered when a meter reader is manually reading scalar meters.

Reader remark types are submitted with scalar initial measurements when received from a head-end system or meter read collection system. Reader remarks are NOT uploaded along with other device events. Reader remarks are ALWAYS associated with a scalar initial measurement.

Understanding Reader Remark Processing

This section provides an overview of the process that takes place when reader remarks are received within a scalar measurement. For each step in the process, the table below provides a brief description of the processing that takes place, and lists the specific objects used by the Service and Measurement Data Foundation

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

Step

Process

Service and Measurement Data Foundation Objects

1.

The system receives an initial measurement from a manually-read scalar device that contains one or more reader remark types.

The base package "Initial Load IMD (Scalar)" (D1-IntialLoadIMDScalar) business object supports inclusion of one or more reader remark types.

2.

When the initial measurement enters the Finalized state, an Enter algorithm creates a reader remark for each reader remark type included in the initial measurement.

Note: Creation of reader remarks does NOT make use of device event mapping extendable lookups.

Algorithm: D1-CRE-RR (Create Reader Remark)

3.

Reader remarks begin in the Pending state. They are transitioned to the Execute state either manually or via batch processing.

The Execute state contains a number of Enter algorithms that perform the following

•

Determine if the reader remark is eligible for processing, based on the "Eligible for Processing" flag on the reader remark type

•

Create a To Do Entry based on the "To Do Type" and "To Do Role" defined on the reader remark type

•

Create a service issue monitor based on the service issue monitor specified on the reader remark type

•

Send the reader remark to subscribing systems

Batch Control: D1-DVEVT (Device Event MO Periodic Monitor Process)

Algorithm: D1-RR-ELIG (Reader Remark Eligibility)

Algorithm: D1-CRE-RR-TD (Create To Do Entry for Reader Remark)

Algorithm: D1-DVCEVTSIM (Create Service Issue Monitor for Reader Remark)

Algorithm: D1-RRSENDSUB (Send to Subscribers for Reader Remark)

Sending Reader Remarks to Subscribing Systems

Reader remarks can be passed onto to other subscribing systems such as a customer information system (such as Oracle Utilities Customer Care and Billing), an outage system (such as Oracle Utilities Network Management System), or some other application.

Reader remarks are sent to subscribing systems when they enter the Execute state. An Enter algorithm (D1-RRSENDSUB /Send to Subscribers for Reader Remark in the base package) determines which service providers (external systems) are interested in receiving the current reader remark based upon its type and category, finds the processing method for each, and processes the device event accordingly.

The means of sending reader remark information to subscribing systems is defined in the "How to Send Device Event Related Information" processing method for the service provider representing the subscribing system. Reader remark information can be sent via outbound communication business object, outbound communication, or batch process.

The method for sending device events to subscribing systems (business object, outbound message, or batch process) is defined for the "Reader Remark" device event category, and can be overridden for individual reader remark types (including the ability to exclude specific reader remark types. In addition, a default event processing method can be also be configured that applies when methods of transmission aren't specified at the individual category level.

The "Subscribe to Device Event" business service is used to process reader remark subscription requests, and allow external applications to manage the categories of events they receive.

Reader Remarks and Service Issue Monitors

Like other device events, reader remarks can create service issue monitors. See Service Issue Monitors and Service Investigative Orders in Chapter 8: Device Communication and Device Events for more information about service issue monitors.

Subtractive Measuring Components

Initial measurement data for subtractive measuring components (such as most scalar measuring components) also typically contain start and stop readings in addition to Pre and Post VEE usage. For example, a set of initial measurements for s subtractive scalar measuring component might look like the following:

Date / Time

Start Reading

Stop Reading

Pre VEE Usage

Pre VEE Condition

Post VEE Value

Post VEE Usage

01/01/2010 3:00 PM

0

1500

1500

Regular

1515

Regular

02/2/2010 4:11 PM

1500

2100

600

Regular

606

Regular

03/03/2010 5:22 PM

2100

2900

800

Regular

808

Regular

04/01/2010 1:00 PM

2900

3500

600

Regular

606

Regular

Rollover Calculations

Subtractive measuring components can "rollover" when the reading exceeds the maximum value based on the number of dials. For example, a register with a 4 dials can record values up to 9999 before rolling over to 0000. When this occurs, consumption is calculated based on the following attributes and calculated values.

•

Rollover Threshold is the percentage of the measuring component's dial capacity at which measurements for measuring components of this type are considered to have rolled over. Dial capacity is the largest value that can be recorded for the measuring component, based on the measuring component's number of dials. For example, a measuring component with 5 dials has a dial capacity of 99999.

•

MaxDialCapacity is the maximum value for the number of dials, rounded up to the next whole multiple of 10 (or 10 raised to the power of the number of dials). For example, for a register with 4 dials, the MaxDialValue is 10000.

•

MaxAcceptableDifference is the maximum acceptable consumption that can be recorded for the register. This is equal to the MaxDialCapacity multiplied by the rollover threshold. For example, the MaxAcceptableDifference for a register with 4 dials and a rollover threshold of 90% would be 9000. If the consumption is greater than this value, the initial measurement is transitioned to the Error state.

•

Difference : The difference between the Stop Reading and Start Reading, obtained by subtracting the Start Reading from the Stop Reading. If the Difference is less than zero (<0), then add the MaxDialCapacity to calculate Rollover.

•

Rollover : The adjusted consumption for a reading on a register that has rolled over. Only applicable if the Difference (Stop Reading - Start Reading) is less than zero (<0).

•

Consumption : The calculated consumption for the reading, equal to either the Difference or Rollover. If the Difference is greater than or equal to zero, consumption is equal to the Difference. If the Difference is less than zero (<0), and the Rollover is less than or equal to the MaxAcceptableDifference, the consumption is equal to the Rollover.

Example : Consider an initial measurement with the following attributes:

•

Number of Dials: 4

•

Rollover Threshold: 90 (%)

•

Start Reading: 8900

•

Stop Reading: 0500

For this reading,

MaxDialCapacity = 10000

MaxAcceptableDifference = 9000 (10000 * .90)

Difference = 0500 (Stop Reading) - 8900 (Start Reading) or -8400

Rollover = 10000 (MaxDialCapacity) + -8400 (Difference) or 1600

Consumption is equal to 1600 (Rollover).

Estimated Initial Measurements

Over the course of time, it may happen that the system will not receive usage for a device for some period of time. When the system detects that a measuring component is missing final measurements, it can creates a initial measurement via estimation. This type of initial measurement is referred to as an estimated initial measurement (as opposed to an Initial Load or Manual initial measurement).

At a high-level, the estimation process is as follows:

•

Missing Measurements are detected by a "Period Estimation" system event algorithm on the measuring component business object

•

Estimated initial measurements are created for the "missing" time period by the "Period Estimation" system event algorithm on the measuring component business object

•

Values and consumption for the estimated initial measurements are calculated by "estimation" VEE rules.

It’s important to note that the processes that detect missing measurements do NOT themselves estimate consumption. Rather, these detection processes simply create an initial measurement and let the estimation VEE rules estimate the consumption for the initial measurement.

Detecting Missing Measurements

The detection of missing measurements occurs at different points in time for interval and scalar measuring components:

•

For interval measuring components, a dedicated batch process exists to initiate creation of estimated initial measurements

•

For manually read scalar measuring components, a usage calculation rule creates the initial measurement if it cannot find a measurement and it has been given permission to estimate. (Note: the information that follows applies primarily to interval measuring components).

The batch process that detects missing consumption for interval measuring components uses two elements on interval measurinng component type:

•

Hours Before Estimation : the number of hours after the End Date and Time of the most recent measurement that must pass before the measuring component is considered due for estimation. For example, if set to 72 hours, estimation will only take place 72 hours after the End Date and Time of the latest measurement.

•

Number of Hours to Estimate : the number of hours of measurement data that are estimated when estimation is performed for the measuring component.

If a measuring component has contiguous final measurements on/after a date and time equal to the current date/time minus the "Hours Before Estimate" value, the measuring component is not estimated.

If the measuring component does NOT have contiguous final measurements on/after a date and time equal to the current date/time minus the "Hours Before Estimate" value, the measuring component is estimated. If the measuring component is subject to estimation, measurements will be estimated through the a date and time equal to the current date/time minus the (Hours Before Estimation - Number of Hours to Estimate).

The following examples illustrate how the system determines if estimation should take place. These examples are all assume a measuring component whose measuring component type specifies an "Hours Before Estimation" of 72 (3 days) and a "Number of Hours to Estimate" of 24 (1 day).

Example 1 : On January 9, if there is contiguous consumption through January 7, estimation would not occur because consumption exists after January 6 (3 days prior to January 9). The diagram below illustrates this example:

Example 2 : On Janury 9 if contiguous consumption existed through January 2, estimation would take place because consumption does not exist through January 6 (3 days prior to January 9). In this example, consumption would be estimated for missing intervals from January 2 through January 7 (January 9 minus 48 hours (Hours Before Estimation minus Number of Hours to Estimate). Note that this assumes that period estimation had NOT been run after January 5. The diagram below illustrates this example:

Example 3 : On Janury 9 if contiguous consumption existed through January 2 and for January 5 (but NOT for January 3-4 or 6-7), two initial measurements would be created, one for January 3-4, and another for January 6-7. The diagram below illustrates this example:

Estimation Algorithms

Estimation for interval measuring components is detected and initiated by two algorithms, one on the device business object, and the other on the measuring component business object.

Devices whose measuring components are subject to periodic estimation (in most cases, interval measuring components) have a "Period Estimation" Monitor algorithm (D1-PERESTM) on their Active state. This monitoring algorithm retrieves the device's measuring component and invokes the algorithm on the "Periodic Estimation" system event on the measuring component business object. Note - the device monitoring algorithm can be configured to look at device configurations from a number of days in the past defined by an algorithm parameter. The base package includes this algorithm on the Active state of the Smart Meter (D1-SmartMeter) device business object. The "Periodic Estimation" monitor algorithm can be triggered by the "Smart Meter State Monitor Process" batch process (D1-SMMTR).

The "Periodic Estimation" System Event algorithm determines if a measuring component is missing final measurements (as described above), and if final measurements are missing, estimates initial measurements and/or creates a To Do Entry. In the base package, this algorithm is the "Create Initial Measurement and To Do Entry" algorithm (D1-CRIMTODO). Algorithm parameters can specify if an initial measurement is to be created, if an To Do Entry is to be created, and the To Do Type and Role (if applicable) for any To Do entries created. The base package includes this algorithm on the Period Estimation system event state of the Interval Channel (D1-IntervalChannel) measuring component business object.

Estimation Calculations

When new estimated initial measurements are created (for either interval or scalar measuring components), the Pre-VEE and Post-VEE values are initially set to zero. When the initial measurement enters the "VEE Complete" state, the VEE rules within the VEE group defined for the "Estimation" VEE role (defined by the "VEE Group For Estimation" field on the measuring component) calculate values and consumption for the initial measurement.

Note that the VEE rules used in this process can also include validation rules that perform validation on the estimated values and consumption. For example, the "estimation" VEE group might contain rules to estimate interval values from a profile, and then perform a sum check to validate the resulting interval measurement against measurements from a consumption reference measuring component. In this example, the sum check validation would be configured to be applied after the interval profile estimation.

Estimated initial measurements are created using "estimation" initial measurement business objects. The base package includes the Estimation IMD (Interval) and Estimation IMD (Scalar) business objects (D1-EstimationIMDInterval or D1-EstimationIMDScalar, respectively).

Initial Measurement Data

Measurements read from a measuring component are referred to as "initial measurement data" (or initial measurements) and are used to record how much of the quantity (defined by UOM, TOU, and SQI) measured by the measuring component was consumed.

Initial measurement data for scalar measuring components contain a single "reading" or value, while initial measurement data for interval measuring components can contain multiple readings, one for each interval that falls between the start time and stop time of the measurement.

At a simple level, initial measurement data goes through the following process:

1.

Initial measurements are loaded into the system.

2.

Initial measurement data is validated, edited, and estimated.

3.

Initial measurements are converted into final measurements.

4.

Final measurements are used to calculate usage (bill determinants, etc.).

Creating Initial Measurements

The IMD Seeder business object (D1-IMDSeeder) is used to create initial measurements (via instantiating initial measurement business objects), based on the head-end system sending the measurement. The "Initial Measurement Creation" processing method defined for the head-end system service provider defines the specific type of initial measurement to create. If for some reason an initial measurement can’t be created, an instance of the IMD Seeder business object is created to allow tracking of the error (and once the error is resolved, the IMD Seeder instance can be reprocessed.

The IMD Seeder business object determines the service provider and measuring component for the measurement (based on attributes supplied in the incoming reading, such as device ID, external reference ID, etc.). This is performed by the "Derive Service Provider and Measuring Component" pre-processing algorithm (D1-DER-SPRMC).

If the service provider is not specified on the device, the algorithm tries to derive it from the device type. Otherwise, it attempts to derive the service provider from the measurement cycle route from the service point at which the device is installed (if available).

The IMD Seeder also ensures that the Start and End Date/Time fields on the initial measurement are populated, deriving them from the incoming reading if necessary. This step is performed by the "Derive IMD Date/Time Values" pre-processing algorithm (D1-VALDR-INP).

Critical Validations

The IMD Seeder also performs a series of critical validations to ensure that the incokming reading contains valid data. These critical validations include validating that the device identifier supplied is valid and exists in the system, and performing Undercount and Overcount checks for interval readings.

•

Device Identifier : Device identifier checks validate that the device identifier provided with the measurement is valid. Device identifiers can include serial number, badge number, channel ID, etc.

•

Undercount : An undercount occurs when an interval initial measurement contains fewer interval values than approrpriate based on the interval size (or seconds-per-interval, or SPI) and the Start and End Date/Time values. For example, if an initial measurement has an interval size of one hour (or an SPI of 3600), and a Start Date/Time is October 27, 2011 and End Date/Time of October 28, 2011 (a total duration of 1 day), it should contain 24 interval values. If it contained less than 24 interval values, it could consitute an undercount.

•

Overcount : An overcount occurs when an interval initial measurement contains more interval values than approrpriate based on the interval size (or seconds-per-interval, or SPI) and the Start and End Date/Time values. For example, if an initial measurement has an interval size of one hour (or an SPI of 3600), and a Start Date/Time is October 27, 2011 and End Date/Time of October 28, 2011 (a total duration of 1 day), it should contain 24 interval values. If it contained more than 24 interval values, it could consitute an overcount.

If an incoming interval initial measurement contains either an invalid device identifier, an undercount, or an overcount, the measurement is rejected, and an instance of the IMD Seeder business object is created. Undercount and Overcount checks are performed by the "Perform Date/Time Adjustments and Undercount/Overcount Check" pre-processing algorithm (D1-DODTTMADJ).

Time Zone Translation

If your organization receives initial measurement from a source that provides its data in a different time zone than the one in which the data will be stored in Oracle Utilities Meter Data Management, a translation can be performed to translate the time zone from an external time zone identifier to one configured within the application. This translation is defined via the Head-End Time Zone to Standard Mapping extendable lookup.

Validation, Editing, and Estimation

Once received into the system, initial measurements are subject to validation, editing, and estimation. This process involves the following:

•

Validation : Validates that the initial measurement data is within expected tolerances, and is correct

•

Editing : If the initial measurement data is wrong in some way, the data can be automatically changed.

•

Estimation : If initial measurement data is incomplete (for example, if one or more interval values within an interval measurement are missing), missing values can be automatically estimated.

As noted above, the values recorded in an initial measurement can change during the validation, editing, and estimation processing, and exceptions can be raised if initial measurements are wrong in some way (such as out-of-tolerance quantities, incorrect values, etc.).

Note : The validation, editing, and estimation process is referred to as VEE, and is described in more detail in a later chapter.

Skipping VEE Processing - High Quality Check for Interval Initial Measurements

Execution of VEE rules is performed by an Enter algorithm on the "VEE Complete" state of the initial measurement business object. For interval initial measurements, the "High Quality Check - Vector Band Based" (D1-HIGHQUALV) algorithm can be used to skip VEE processing and transition the initial measurement directly to the "Finalized" state.

This algorithm checks whether the intervals within an initial measurement are considered to be of "high quality" (defined below), and if they are considered "high quality", the algorithm transitions the current initial measurement directly to the "Finalized" state.

An interval initial measurement is considered to be of "high quality" if the following conditions are met:

•

There are no missing intervals in the initial measurement

•

All interval values are within a range that extends above and below final interval values for the corresponding intervals from the previous reading. The range is defined by the "Low Tolerance" and "High Tolerance" algorithm parameters. These parameters define mutipliers that are applied to the corresponding interval from the previous reading. The "Low Tolerance" is subtracted from the previous reading’s final measurement, and the "High Tolerance" is added the the previous reading’s final measurement to define the range within which each interval must fall.

For example, if the previous reading’s final measurement value at 1:00 AM was 20, and the "Low Tolerance" parameter is set to 0.2 and the "High Tolerance" parameter is set to 0.25, the initial measurement’s value at 1:00 AM must be between between 16 (20 - 0.2*20) and 25 (20 + 0.25*20).

•

All intervals have a condition code that falls between the range defined by the "Default Bottom Range Condition Value" and "Default Top Range Condition Value" algorithm parameters.

If the initial measurement fails any part of the high quality assessment, the routine simply exits.

Pre VEE and Post VEE Quantities

Initial measurement data contains both the original and final versions of the quantities recorded by the measuring component.

•

Pre VEE quantities are consumption values derived from the measurements recorded by the head-end system or meter reader.

•

Post VEE quantities are the "final" values, after VEE processing.

Pre VEE and Post VEE quantities in an initial measurement often differ based on a number of conditions, including:

1.

The measuring component has a multiplier other than 1.

In this case, the Post VEE value is equal to the Pre VEE value times the multiplier.

2.

The installation event has a constant other than 1.

In this case, the Post VEE value is equal to the Pre VEE value times the installation constant.

3.

VEE rules have changed the quantities because they are missing or obviously wrong

In this, the Pre VEE values are adjusted based on the specifics of the VEE rules applied to the initial measurement to create the Post VEE values

4.

Manual changes by a user.

Condition Codes

In addition to recorded consumption values, measurements also have condition codes, used to indicate the source and quality of a measurement. For example:

•

Regularly recorded measurements might have a condition code of "Regular"

•

Missing measurements might have a condition code of "Missing"

•

Estimated measurements might have a condition code of "External Estimated" or "System Estimated" based on where the estimation was performed.

Both Pre VEE and Post VEE values have their own condition code, which can also change during VEE processing. For example, consider the following sample measurements from an interval measuring component:

Date / Time

Pre VEE Value

Pre VEE Condition

Post VEE Value

Post VEE Condition

01/01/2010 3:00 PM

14.678

Regular

15.1

Regular

01/01/2010 4:00 PM

Missing

20

Estimated

01/01/2010 5:00 PM

13.12

Regular

13.41

Regular

01/01/2010 6:00 PM

150.12

Regular

14.12

Estimated

For the 4:00 PM interval, note the Pre VEE condition indicates the interval is missing and the Post VEE condition highlights that it was estimated.

For the 6:00 PM interval (containing a spike, or an interval with conspicuously high usage relative to surrounding intervals), note that the system head-end (the system that recorded the measurement) indicated the interval value was fine (Pre VEE is regular), but the VEE process smoothed it, and set the Post VEE condition to "Estimated."

Condition Codes Extendable Lookup

Condition codes are defined in the Measurement Condition extendable lookup (D1-MeasurementConditionLookup). Base package condition codes delivered in this extendable lookup include the following:

Condition Code (Value)

Description

100000

No Read - System

101000

No Read - Outage

201000

Missing

301000

System Estimate

401000

External Estimate

402000

Office Estimate

501000

Regular

901000

Super

Additional condition codes can be added to this extendable lookup to meet requirements specific to individual implementations. Gaps between the base package condition code values allow custom condition codes to be added that represent data with conditions that fall between the base package conditions. For example, a condition code to indicate that the measurement was estimated based on partially incomplete data (and is considered to be of worse quality than "System Estimate", but better than "Missing") would fall somewhere between 201000 and 301000.

As a general rule, condition codes used to represent bad data or error conditions should be smaller than condition codes used to represent good data.’

Reader Remarks and Scalar Measurements

Initial measurements for manually-read scalar meters can create reader remarks. Reader remarks are a specific type of device event used to capture and/or record specific events or circumstances encountered when a meter reader is manually reading scalar meters.

Reader remark types are submitted with scalar initial measurements when received from a head-end system or meter read collection system. Reader remarks are NOT uploaded along with other device events. Reader remarks are ALWAYS associated with a scalar initial measurement.

Understanding Reader Remark Processing

This section provides an overview of the process that takes place when reader remarks are received within a scalar measurement. For each step in the process, the table below provides a brief description of the processing that takes place, and lists the specific objects used by the Service and Measurement Data Foundation

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

Step

Process

Service and Measurement Data Foundation Objects

1.

The system receives an initial measurement from a manually-read scalar device that contains one or more reader remark types.

The base package "Initial Load IMD (Scalar)" (D1-IntialLoadIMDScalar) business object supports inclusion of one or more reader remark types.

2.

When the initial measurement enters the Finalized state, an Enter algorithm creates a reader remark for each reader remark type included in the initial measurement.

Note: Creation of reader remarks does NOT make use of device event mapping extendable lookups.

Algorithm: D1-CRE-RR (Create Reader Remark)

3.

Reader remarks begin in the Pending state. They are transitioned to the Execute state either manually or via batch processing.

The Execute state contains a number of Enter algorithms that perform the following

•

Determine if the reader remark is eligible for processing, based on the "Eligible for Processing" flag on the reader remark type

•

Create a To Do Entry based on the "To Do Type" and "To Do Role" defined on the reader remark type

•

Create a service issue monitor based on the service issue monitor specified on the reader remark type

•

Send the reader remark to subscribing systems

Batch Control: D1-DVEVT (Device Event MO Periodic Monitor Process)

Algorithm: D1-RR-ELIG (Reader Remark Eligibility)

Algorithm: D1-CRE-RR-TD (Create To Do Entry for Reader Remark)

Algorithm: D1-DVCEVTSIM (Create Service Issue Monitor for Reader Remark)

Algorithm: D1-RRSENDSUB (Send to Subscribers for Reader Remark)

Sending Reader Remarks to Subscribing Systems

Reader remarks can be passed onto to other subscribing systems such as a customer information system (such as Oracle Utilities Customer Care and Billing), an outage system (such as Oracle Utilities Network Management System), or some other application.

Reader remarks are sent to subscribing systems when they enter the Execute state. An Enter algorithm (D1-RRSENDSUB /Send to Subscribers for Reader Remark in the base package) determines which service providers (external systems) are interested in receiving the current reader remark based upon its type and category, finds the processing method for each, and processes the device event accordingly.

The means of sending reader remark information to subscribing systems is defined in the "How to Send Device Event Related Information" processing method for the service provider representing the subscribing system. Reader remark information can be sent via outbound communication business object, outbound communication, or batch process.

The method for sending device events to subscribing systems (business object, outbound message, or batch process) is defined for the "Reader Remark" device event category, and can be overridden for individual reader remark types (including the ability to exclude specific reader remark types. In addition, a default event processing method can be also be configured that applies when methods of transmission aren't specified at the individual category level.

The "Subscribe to Device Event" business service is used to process reader remark subscription requests, and allow external applications to manage the categories of events they receive.

Reader Remarks and Service Issue Monitors

Like other device events, reader remarks can create service issue monitors. See Service Issue Monitors and Service Investigative Orders in Chapter 8: Device Communication and Device Events for more information about service issue monitors.

Subtractive Measuring Components

Initial measurement data for subtractive measuring components (such as most scalar measuring components) also typically contain start and stop readings in addition to Pre and Post VEE usage. For example, a set of initial measurements for s subtractive scalar measuring component might look like the following:

Date / Time

Start Reading

Stop Reading

Pre VEE Usage

Pre VEE Condition

Post VEE Value

Post VEE Usage

01/01/2010 3:00 PM

0

1500

1500

Regular

1515

Regular

02/2/2010 4:11 PM

1500

2100

600

Regular

606

Regular

03/03/2010 5:22 PM

2100

2900

800

Regular

808

Regular

04/01/2010 1:00 PM

2900

3500

600

Regular

606

Regular

Rollover Calculations

Subtractive measuring components can "rollover" when the reading exceeds the maximum value based on the number of dials. For example, a register with a 4 dials can record values up to 9999 before rolling over to 0000. When this occurs, consumption is calculated based on the following attributes and calculated values.

•

Rollover Threshold is the percentage of the measuring component's dial capacity at which measurements for measuring components of this type are considered to have rolled over. Dial capacity is the largest value that can be recorded for the measuring component, based on the measuring component's number of dials. For example, a measuring component with 5 dials has a dial capacity of 99999.

•

MaxDialCapacity is the maximum value for the number of dials, rounded up to the next whole multiple of 10 (or 10 raised to the power of the number of dials). For example, for a register with 4 dials, the MaxDialValue is 10000.

•

MaxAcceptableDifference is the maximum acceptable consumption that can be recorded for the register. This is equal to the MaxDialCapacity multiplied by the rollover threshold. For example, the MaxAcceptableDifference for a register with 4 dials and a rollover threshold of 90% would be 9000. If the consumption is greater than this value, the initial measurement is transitioned to the Error state.

•

Difference : The difference between the Stop Reading and Start Reading, obtained by subtracting the Start Reading from the Stop Reading. If the Difference is less than zero (<0), then add the MaxDialCapacity to calculate Rollover.

•

Rollover : The adjusted consumption for a reading on a register that has rolled over. Only applicable if the Difference (Stop Reading - Start Reading) is less than zero (<0).

•

Consumption : The calculated consumption for the reading, equal to either the Difference or Rollover. If the Difference is greater than or equal to zero, consumption is equal to the Difference. If the Difference is less than zero (<0), and the Rollover is less than or equal to the MaxAcceptableDifference, the consumption is equal to the Rollover.

Example : Consider an initial measurement with the following attributes:

•

Number of Dials: 4

•

Rollover Threshold: 90 (%)

•

Start Reading: 8900

•

Stop Reading: 0500

For this reading,

MaxDialCapacity = 10000

MaxAcceptableDifference = 9000 (10000 * .90)

Difference = 0500 (Stop Reading) - 8900 (Start Reading) or -8400

Rollover = 10000 (MaxDialCapacity) + -8400 (Difference) or 1600

Consumption is equal to 1600 (Rollover).

Estimated Initial Measurements

Over the course of time, it may happen that the system will not receive usage for a device for some period of time. When the system detects that a measuring component is missing final measurements, it can creates a initial measurement via estimation. This type of initial measurement is referred to as an estimated initial measurement (as opposed to an Initial Load or Manual initial measurement).

At a high-level, the estimation process is as follows:

•

Missing Measurements are detected by a "Period Estimation" system event algorithm on the measuring component business object

•

Estimated initial measurements are created for the "missing" time period by the "Period Estimation" system event algorithm on the measuring component business object

•

Values and consumption for the estimated initial measurements are calculated by "estimation" VEE rules.

It’s important to note that the processes that detect missing measurements do NOT themselves estimate consumption. Rather, these detection processes simply create an initial measurement and let the estimation VEE rules estimate the consumption for the initial measurement.

Detecting Missing Measurements

The detection of missing measurements occurs at different points in time for interval and scalar measuring components:

•

For interval measuring components, a dedicated batch process exists to initiate creation of estimated initial measurements

•

For manually read scalar measuring components, a usage calculation rule creates the initial measurement if it cannot find a measurement and it has been given permission to estimate. (Note: the information that follows applies primarily to interval measuring components).

The batch process that detects missing consumption for interval measuring components uses two elements on interval measurinng component type:

•

Hours Before Estimation : the number of hours after the End Date and Time of the most recent measurement that must pass before the measuring component is considered due for estimation. For example, if set to 72 hours, estimation will only take place 72 hours after the End Date and Time of the latest measurement.

•

Number of Hours to Estimate : the number of hours of measurement data that are estimated when estimation is performed for the measuring component.

If a measuring component has contiguous final measurements on/after a date and time equal to the current date/time minus the "Hours Before Estimate" value, the measuring component is not estimated.

If the measuring component does NOT have contiguous final measurements on/after a date and time equal to the current date/time minus the "Hours Before Estimate" value, the measuring component is estimated. If the measuring component is subject to estimation, measurements will be estimated through the a date and time equal to the current date/time minus the (Hours Before Estimation - Number of Hours to Estimate).

The following examples illustrate how the system determines if estimation should take place. These examples are all assume a measuring component whose measuring component type specifies an "Hours Before Estimation" of 72 (3 days) and a "Number of Hours to Estimate" of 24 (1 day).

Example 1 : On January 9, if there is contiguous consumption through January 7, estimation would not occur because consumption exists after January 6 (3 days prior to January 9). The diagram below illustrates this example:

Example 2 : On Janury 9 if contiguous consumption existed through January 2, estimation would take place because consumption does not exist through January 6 (3 days prior to January 9). In this example, consumption would be estimated for missing intervals from January 2 through January 7 (January 9 minus 48 hours (Hours Before Estimation minus Number of Hours to Estimate). Note that this assumes that period estimation had NOT been run after January 5. The diagram below illustrates this example:

Example 3 : On Janury 9 if contiguous consumption existed through January 2 and for January 5 (but NOT for January 3-4 or 6-7), two initial measurements would be created, one for January 3-4, and another for January 6-7. The diagram below illustrates this example:

Estimation Algorithms

Estimation for interval measuring components is detected and initiated by two algorithms, one on the device business object, and the other on the measuring component business object.

Devices whose measuring components are subject to periodic estimation (in most cases, interval measuring components) have a "Period Estimation" Monitor algorithm (D1-PERESTM) on their Active state. This monitoring algorithm retrieves the device's measuring component and invokes the algorithm on the "Periodic Estimation" system event on the measuring component business object. Note - the device monitoring algorithm can be configured to look at device configurations from a number of days in the past defined by an algorithm parameter. The base package includes this algorithm on the Active state of the Smart Meter (D1-SmartMeter) device business object. The "Periodic Estimation" monitor algorithm can be triggered by the "Smart Meter State Monitor Process" batch process (D1-SMMTR).

The "Periodic Estimation" System Event algorithm determines if a measuring component is missing final measurements (as described above), and if final measurements are missing, estimates initial measurements and/or creates a To Do Entry. In the base package, this algorithm is the "Create Initial Measurement and To Do Entry" algorithm (D1-CRIMTODO). Algorithm parameters can specify if an initial measurement is to be created, if an To Do Entry is to be created, and the To Do Type and Role (if applicable) for any To Do entries created. The base package includes this algorithm on the Period Estimation system event state of the Interval Channel (D1-IntervalChannel) measuring component business object.

Estimation Calculations

When new estimated initial measurements are created (for either interval or scalar measuring components), the Pre-VEE and Post-VEE values are initially set to zero. When the initial measurement enters the "VEE Complete" state, the VEE rules within the VEE group defined for the "Estimation" VEE role (defined by the "VEE Group For Estimation" field on the measuring component) calculate values and consumption for the initial measurement.

Note that the VEE rules used in this process can also include validation rules that perform validation on the estimated values and consumption. For example, the "estimation" VEE group might contain rules to estimate interval values from a profile, and then perform a sum check to validate the resulting interval measurement against measurements from a consumption reference measuring component. In this example, the sum check validation would be configured to be applied after the interval profile estimation.

Estimated initial measurements are created using "estimation" initial measurement business objects. The base package includes the Estimation IMD (Interval) and Estimation IMD (Scalar) business objects (D1-EstimationIMDInterval or D1-EstimationIMDScalar, respectively).

Initial Measurement Data

Measurements read from a measuring component are referred to as "initial measurement data" (or initial measurements) and are used to record how much of the quantity (defined by UOM, TOU, and SQI) measured by the measuring component was consumed.

Initial measurement data for scalar measuring components contain a single "reading" or value, while initial measurement data for interval measuring components can contain multiple readings, one for each interval that falls between the start time and stop time of the measurement.

At a simple level, initial measurement data goes through the following process:

1.

Initial measurements are loaded into the system.

2.

Initial measurement data is validated, edited, and estimated.

3.

Initial measurements are converted into final measurements.

4.

Final measurements are used to calculate usage (bill determinants, etc.).

Creating Initial Measurements

The IMD Seeder business object (D1-IMDSeeder) is used to create initial measurements (via instantiating initial measurement business objects), based on the head-end system sending the measurement. The "Initial Measurement Creation" processing method defined for the head-end system service provider defines the specific type of initial measurement to create. If for some reason an initial measurement can’t be created, an instance of the IMD Seeder business object is created to allow tracking of the error (and once the error is resolved, the IMD Seeder instance can be reprocessed.

The IMD Seeder business object determines the service provider and measuring component for the measurement (based on attributes supplied in the incoming reading, such as device ID, external reference ID, etc.). This is performed by the "Derive Service Provider and Measuring Component" pre-processing algorithm (D1-DER-SPRMC).

If the service provider is not specified on the device, the algorithm tries to derive it from the device type. Otherwise, it attempts to derive the service provider from the measurement cycle route from the service point at which the device is installed (if available).

The IMD Seeder also ensures that the Start and End Date/Time fields on the initial measurement are populated, deriving them from the incoming reading if necessary. This step is performed by the "Derive IMD Date/Time Values" pre-processing algorithm (D1-VALDR-INP).

Critical Validations

The IMD Seeder also performs a series of critical validations to ensure that the incokming reading contains valid data. These critical validations include validating that the device identifier supplied is valid and exists in the system, and performing Undercount and Overcount checks for interval readings.

•

Device Identifier : Device identifier checks validate that the device identifier provided with the measurement is valid. Device identifiers can include serial number, badge number, channel ID, etc.

•

Undercount : An undercount occurs when an interval initial measurement contains fewer interval values than approrpriate based on the interval size (or seconds-per-interval, or SPI) and the Start and End Date/Time values. For example, if an initial measurement has an interval size of one hour (or an SPI of 3600), and a Start Date/Time is October 27, 2011 and End Date/Time of October 28, 2011 (a total duration of 1 day), it should contain 24 interval values. If it contained less than 24 interval values, it could consitute an undercount.

•

Overcount : An overcount occurs when an interval initial measurement contains more interval values than approrpriate based on the interval size (or seconds-per-interval, or SPI) and the Start and End Date/Time values. For example, if an initial measurement has an interval size of one hour (or an SPI of 3600), and a Start Date/Time is October 27, 2011 and End Date/Time of October 28, 2011 (a total duration of 1 day), it should contain 24 interval values. If it contained more than 24 interval values, it could consitute an overcount.

If an incoming interval initial measurement contains either an invalid device identifier, an undercount, or an overcount, the measurement is rejected, and an instance of the IMD Seeder business object is created. Undercount and Overcount checks are performed by the "Perform Date/Time Adjustments and Undercount/Overcount Check" pre-processing algorithm (D1-DODTTMADJ).

Time Zone Translation

If your organization receives initial measurement from a source that provides its data in a different time zone than the one in which the data will be stored in Oracle Utilities Meter Data Management, a translation can be performed to translate the time zone from an external time zone identifier to one configured within the application. This translation is defined via the Head-End Time Zone to Standard Mapping extendable lookup.

Validation, Editing, and Estimation

Once received into the system, initial measurements are subject to validation, editing, and estimation. This process involves the following:

•

Validation : Validates that the initial measurement data is within expected tolerances, and is correct

•

Editing : If the initial measurement data is wrong in some way, the data can be automatically changed.

•

Estimation : If initial measurement data is incomplete (for example, if one or more interval values within an interval measurement are missing), missing values can be automatically estimated.

As noted above, the values recorded in an initial measurement can change during the validation, editing, and estimation processing, and exceptions can be raised if initial measurements are wrong in some way (such as out-of-tolerance quantities, incorrect values, etc.).

Note : The validation, editing, and estimation process is referred to as VEE, and is described in more detail in a later chapter.

Skipping VEE Processing - High Quality Check for Interval Initial Measurements

Execution of VEE rules is performed by an Enter algorithm on the "VEE Complete" state of the initial measurement business object. For interval initial measurements, the "High Quality Check - Vector Band Based" (D1-HIGHQUALV) algorithm can be used to skip VEE processing and transition the initial measurement directly to the "Finalized" state.

This algorithm checks whether the intervals within an initial measurement are considered to be of "high quality" (defined below), and if they are considered "high quality", the algorithm transitions the current initial measurement directly to the "Finalized" state.

An interval initial measurement is considered to be of "high quality" if the following conditions are met:

•

There are no missing intervals in the initial measurement

•

All interval values are within a range that extends above and below final interval values for the corresponding intervals from the previous reading. The range is defined by the "Low Tolerance" and "High Tolerance" algorithm parameters. These parameters define mutipliers that are applied to the corresponding interval from the previous reading. The "Low Tolerance" is subtracted from the previous reading’s final measurement, and the "High Tolerance" is added the the previous reading’s final measurement to define the range within which each interval must fall.

For example, if the previous reading’s final measurement value at 1:00 AM was 20, and the "Low Tolerance" parameter is set to 0.2 and the "High Tolerance" parameter is set to 0.25, the initial measurement’s value at 1:00 AM must be between between 16 (20 - 0.2*20) and 25 (20 + 0.25*20).

•

All intervals have a condition code that falls between the range defined by the "Default Bottom Range Condition Value" and "Default Top Range Condition Value" algorithm parameters.

If the initial measurement fails any part of the high quality assessment, the routine simply exits.

Pre VEE and Post VEE Quantities

Initial measurement data contains both the original and final versions of the quantities recorded by the measuring component.

•

Pre VEE quantities are consumption values derived from the measurements recorded by the head-end system or meter reader.

•

Post VEE quantities are the "final" values, after VEE processing.

Pre VEE and Post VEE quantities in an initial measurement often differ based on a number of conditions, including:

1.

The measuring component has a multiplier other than 1.

In this case, the Post VEE value is equal to the Pre VEE value times the multiplier.

2.

The installation event has a constant other than 1.

In this case, the Post VEE value is equal to the Pre VEE value times the installation constant.

3.

VEE rules have changed the quantities because they are missing or obviously wrong

In this, the Pre VEE values are adjusted based on the specifics of the VEE rules applied to the initial measurement to create the Post VEE values

4.

Manual changes by a user.

Condition Codes

In addition to recorded consumption values, measurements also have condition codes, used to indicate the source and quality of a measurement. For example:

•

Regularly recorded measurements might have a condition code of "Regular"

•

Missing measurements might have a condition code of "Missing"

•

Estimated measurements might have a condition code of "External Estimated" or "System Estimated" based on where the estimation was performed.

Both Pre VEE and Post VEE values have their own condition code, which can also change during VEE processing. For example, consider the following sample measurements from an interval measuring component:

Date / Time

Pre VEE Value

Pre VEE Condition

Post VEE Value

Post VEE Condition

01/01/2010 3:00 PM

14.678

Regular

15.1

Regular

01/01/2010 4:00 PM

Missing

20

Estimated

01/01/2010 5:00 PM

13.12

Regular

13.41

Regular

01/01/2010 6:00 PM

150.12

Regular

14.12

Estimated

For the 4:00 PM interval, note the Pre VEE condition indicates the interval is missing and the Post VEE condition highlights that it was estimated.

For the 6:00 PM interval (containing a spike, or an interval with conspicuously high usage relative to surrounding intervals), note that the system head-end (the system that recorded the measurement) indicated the interval value was fine (Pre VEE is regular), but the VEE process smoothed it, and set the Post VEE condition to "Estimated."

Condition Codes Extendable Lookup

Condition codes are defined in the Measurement Condition extendable lookup (D1-MeasurementConditionLookup). Base package condition codes delivered in this extendable lookup include the following:

Condition Code (Value)

Description

100000

No Read - System

101000

No Read - Outage

201000

Missing

301000

System Estimate

401000

External Estimate

402000

Office Estimate

501000

Regular

901000

Super

Additional condition codes can be added to this extendable lookup to meet requirements specific to individual implementations. Gaps between the base package condition code values allow custom condition codes to be added that represent data with conditions that fall between the base package conditions. For example, a condition code to indicate that the measurement was estimated based on partially incomplete data (and is considered to be of worse quality than "System Estimate", but better than "Missing") would fall somewhere between 201000 and 301000.

As a general rule, condition codes used to represent bad data or error conditions should be smaller than condition codes used to represent good data.’

Reader Remarks and Scalar Measurements

Initial measurements for manually-read scalar meters can create reader remarks. Reader remarks are a specific type of device event used to capture and/or record specific events or circumstances encountered when a meter reader is manually reading scalar meters.

Reader remark types are submitted with scalar initial measurements when received from a head-end system or meter read collection system. Reader remarks are NOT uploaded along with other device events. Reader remarks are ALWAYS associated with a scalar initial measurement.

Understanding Reader Remark Processing

This section provides an overview of the process that takes place when reader remarks are received within a scalar measurement. For each step in the process, the table below provides a brief description of the processing that takes place, and lists the specific objects used by the Service and Measurement Data Foundation

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

Step

Process

Service and Measurement Data Foundation Objects

1.

The system receives an initial measurement from a manually-read scalar device that contains one or more reader remark types.

The base package "Initial Load IMD (Scalar)" (D1-IntialLoadIMDScalar) business object supports inclusion of one or more reader remark types.

2.

When the initial measurement enters the Finalized state, an Enter algorithm creates a reader remark for each reader remark type included in the initial measurement.

Note: Creation of reader remarks does NOT make use of device event mapping extendable lookups.

Algorithm: D1-CRE-RR (Create Reader Remark)

3.

Reader remarks begin in the Pending state. They are transitioned to the Execute state either manually or via batch processing.

The Execute state contains a number of Enter algorithms that perform the following

•

Determine if the reader remark is eligible for processing, based on the "Eligible for Processing" flag on the reader remark type

•

Create a To Do Entry based on the "To Do Type" and "To Do Role" defined on the reader remark type

•

Create a service issue monitor based on the service issue monitor specified on the reader remark type

•

Send the reader remark to subscribing systems

Batch Control: D1-DVEVT (Device Event MO Periodic Monitor Process)

Algorithm: D1-RR-ELIG (Reader Remark Eligibility)

Algorithm: D1-CRE-RR-TD (Create To Do Entry for Reader Remark)

Algorithm: D1-DVCEVTSIM (Create Service Issue Monitor for Reader Remark)

Algorithm: D1-RRSENDSUB (Send to Subscribers for Reader Remark)

Sending Reader Remarks to Subscribing Systems

Reader remarks can be passed onto to other subscribing systems such as a customer information system (such as Oracle Utilities Customer Care and Billing), an outage system (such as Oracle Utilities Network Management System), or some other application.

Reader remarks are sent to subscribing systems when they enter the Execute state. An Enter algorithm (D1-RRSENDSUB /Send to Subscribers for Reader Remark in the base package) determines which service providers (external systems) are interested in receiving the current reader remark based upon its type and category, finds the processing method for each, and processes the device event accordingly.

The means of sending reader remark information to subscribing systems is defined in the "How to Send Device Event Related Information" processing method for the service provider representing the subscribing system. Reader remark information can be sent via outbound communication business object, outbound communication, or batch process.

The method for sending device events to subscribing systems (business object, outbound message, or batch process) is defined for the "Reader Remark" device event category, and can be overridden for individual reader remark types (including the ability to exclude specific reader remark types. In addition, a default event processing method can be also be configured that applies when methods of transmission aren't specified at the individual category level.

The "Subscribe to Device Event" business service is used to process reader remark subscription requests, and allow external applications to manage the categories of events they receive.

Reader Remarks and Service Issue Monitors

Like other device events, reader remarks can create service issue monitors. See Service Issue Monitors and Service Investigative Orders in Chapter 8: Device Communication and Device Events for more information about service issue monitors.

Subtractive Measuring Components

Initial measurement data for subtractive measuring components (such as most scalar measuring components) also typically contain start and stop readings in addition to Pre and Post VEE usage. For example, a set of initial measurements for s subtractive scalar measuring component might look like the following:

Date / Time

Start Reading

Stop Reading

Pre VEE Usage

Pre VEE Condition

Post VEE Value

Post VEE Usage

01/01/2010 3:00 PM

0

1500

1500

Regular

1515

Regular

02/2/2010 4:11 PM

1500

2100

600

Regular

606

Regular

03/03/2010 5:22 PM

2100

2900

800

Regular

808

Regular

04/01/2010 1:00 PM

2900

3500

600

Regular

606

Regular

Rollover Calculations

Subtractive measuring components can "rollover" when the reading exceeds the maximum value based on the number of dials. For example, a register with a 4 dials can record values up to 9999 before rolling over to 0000. When this occurs, consumption is calculated based on the following attributes and calculated values.

•

Rollover Threshold is the percentage of the measuring component's dial capacity at which measurements for measuring components of this type are considered to have rolled over. Dial capacity is the largest value that can be recorded for the measuring component, based on the measuring component's number of dials. For example, a measuring component with 5 dials has a dial capacity of 99999.

•

MaxDialCapacity is the maximum value for the number of dials, rounded up to the next whole multiple of 10 (or 10 raised to the power of the number of dials). For example, for a register with 4 dials, the MaxDialValue is 10000.

•

MaxAcceptableDifference is the maximum acceptable consumption that can be recorded for the register. This is equal to the MaxDialCapacity multiplied by the rollover threshold. For example, the MaxAcceptableDifference for a register with 4 dials and a rollover threshold of 90% would be 9000. If the consumption is greater than this value, the initial measurement is transitioned to the Error state.

•

Difference : The difference between the Stop Reading and Start Reading, obtained by subtracting the Start Reading from the Stop Reading. If the Difference is less than zero (<0), then add the MaxDialCapacity to calculate Rollover.

•

Rollover : The adjusted consumption for a reading on a register that has rolled over. Only applicable if the Difference (Stop Reading - Start Reading) is less than zero (<0).

•

Consumption : The calculated consumption for the reading, equal to either the Difference or Rollover. If the Difference is greater than or equal to zero, consumption is equal to the Difference. If the Difference is less than zero (<0), and the Rollover is less than or equal to the MaxAcceptableDifference, the consumption is equal to the Rollover.

Example : Consider an initial measurement with the following attributes:

•

Number of Dials: 4

•

Rollover Threshold: 90 (%)

•

Start Reading: 8900

•

Stop Reading: 0500

For this reading,

MaxDialCapacity = 10000

MaxAcceptableDifference = 9000 (10000 * .90)

Difference = 0500 (Stop Reading) - 8900 (Start Reading) or -8400

Rollover = 10000 (MaxDialCapacity) + -8400 (Difference) or 1600

Consumption is equal to 1600 (Rollover).

Estimated Initial Measurements

Over the course of time, it may happen that the system will not receive usage for a device for some period of time. When the system detects that a measuring component is missing final measurements, it can creates a initial measurement via estimation. This type of initial measurement is referred to as an estimated initial measurement (as opposed to an Initial Load or Manual initial measurement).

At a high-level, the estimation process is as follows:

•

Missing Measurements are detected by a "Period Estimation" system event algorithm on the measuring component business object

•

Estimated initial measurements are created for the "missing" time period by the "Period Estimation" system event algorithm on the measuring component business object

•

Values and consumption for the estimated initial measurements are calculated by "estimation" VEE rules.

It’s important to note that the processes that detect missing measurements do NOT themselves estimate consumption. Rather, these detection processes simply create an initial measurement and let the estimation VEE rules estimate the consumption for the initial measurement.

Detecting Missing Measurements

The detection of missing measurements occurs at different points in time for interval and scalar measuring components:

•

For interval measuring components, a dedicated batch process exists to initiate creation of estimated initial measurements

•

For manually read scalar measuring components, a usage calculation rule creates the initial measurement if it cannot find a measurement and it has been given permission to estimate. (Note: the information that follows applies primarily to interval measuring components).

The batch process that detects missing consumption for interval measuring components uses two elements on interval measurinng component type:

•

Hours Before Estimation : the number of hours after the End Date and Time of the most recent measurement that must pass before the measuring component is considered due for estimation. For example, if set to 72 hours, estimation will only take place 72 hours after the End Date and Time of the latest measurement.

•

Number of Hours to Estimate : the number of hours of measurement data that are estimated when estimation is performed for the measuring component.

If a measuring component has contiguous final measurements on/after a date and time equal to the current date/time minus the "Hours Before Estimate" value, the measuring component is not estimated.

If the measuring component does NOT have contiguous final measurements on/after a date and time equal to the current date/time minus the "Hours Before Estimate" value, the measuring component is estimated. If the measuring component is subject to estimation, measurements will be estimated through the a date and time equal to the current date/time minus the (Hours Before Estimation - Number of Hours to Estimate).

The following examples illustrate how the system determines if estimation should take place. These examples are all assume a measuring component whose measuring component type specifies an "Hours Before Estimation" of 72 (3 days) and a "Number of Hours to Estimate" of 24 (1 day).

Example 1 : On January 9, if there is contiguous consumption through January 7, estimation would not occur because consumption exists after January 6 (3 days prior to January 9). The diagram below illustrates this example:

Example 2 : On Janury 9 if contiguous consumption existed through January 2, estimation would take place because consumption does not exist through January 6 (3 days prior to January 9). In this example, consumption would be estimated for missing intervals from January 2 through January 7 (January 9 minus 48 hours (Hours Before Estimation minus Number of Hours to Estimate). Note that this assumes that period estimation had NOT been run after January 5. The diagram below illustrates this example:

Example 3 : On Janury 9 if contiguous consumption existed through January 2 and for January 5 (but NOT for January 3-4 or 6-7), two initial measurements would be created, one for January 3-4, and another for January 6-7. The diagram below illustrates this example:

Estimation Algorithms

Estimation for interval measuring components is detected and initiated by two algorithms, one on the device business object, and the other on the measuring component business object.

Devices whose measuring components are subject to periodic estimation (in most cases, interval measuring components) have a "Period Estimation" Monitor algorithm (D1-PERESTM) on their Active state. This monitoring algorithm retrieves the device's measuring component and invokes the algorithm on the "Periodic Estimation" system event on the measuring component business object. Note - the device monitoring algorithm can be configured to look at device configurations from a number of days in the past defined by an algorithm parameter. The base package includes this algorithm on the Active state of the Smart Meter (D1-SmartMeter) device business object. The "Periodic Estimation" monitor algorithm can be triggered by the "Smart Meter State Monitor Process" batch process (D1-SMMTR).

The "Periodic Estimation" System Event algorithm determines if a measuring component is missing final measurements (as described above), and if final measurements are missing, estimates initial measurements and/or creates a To Do Entry. In the base package, this algorithm is the "Create Initial Measurement and To Do Entry" algorithm (D1-CRIMTODO). Algorithm parameters can specify if an initial measurement is to be created, if an To Do Entry is to be created, and the To Do Type and Role (if applicable) for any To Do entries created. The base package includes this algorithm on the Period Estimation system event state of the Interval Channel (D1-IntervalChannel) measuring component business object.

Estimation Calculations

When new estimated initial measurements are created (for either interval or scalar measuring components), the Pre-VEE and Post-VEE values are initially set to zero. When the initial measurement enters the "VEE Complete" state, the VEE rules within the VEE group defined for the "Estimation" VEE role (defined by the "VEE Group For Estimation" field on the measuring component) calculate values and consumption for the initial measurement.

Note that the VEE rules used in this process can also include validation rules that perform validation on the estimated values and consumption. For example, the "estimation" VEE group might contain rules to estimate interval values from a profile, and then perform a sum check to validate the resulting interval measurement against measurements from a consumption reference measuring component. In this example, the sum check validation would be configured to be applied after the interval profile estimation.

Estimated initial measurements are created using "estimation" initial measurement business objects. The base package includes the Estimation IMD (Interval) and Estimation IMD (Scalar) business objects (D1-EstimationIMDInterval or D1-EstimationIMDScalar, respectively).

Initial Measurement Data

Measurements read from a measuring component are referred to as "initial measurement data" (or initial measurements) and are used to record how much of the quantity (defined by UOM, TOU, and SQI) measured by the measuring component was consumed.

Initial measurement data for scalar measuring components contain a single "reading" or value, while initial measurement data for interval measuring components can contain multiple readings, one for each interval that falls between the start time and stop time of the measurement.

At a simple level, initial measurement data goes through the following process:

1.

Initial measurements are loaded into the system.

2.

Initial measurement data is validated, edited, and estimated.

3.

Initial measurements are converted into final measurements.

4.

Final measurements are used to calculate usage (bill determinants, etc.).

Creating Initial Measurements

The IMD Seeder business object (D1-IMDSeeder) is used to create initial measurements (via instantiating initial measurement business objects), based on the head-end system sending the measurement. The "Initial Measurement Creation" processing method defined for the head-end system service provider defines the specific type of initial measurement to create. If for some reason an initial measurement can’t be created, an instance of the IMD Seeder business object is created to allow tracking of the error (and once the error is resolved, the IMD Seeder instance can be reprocessed.

The IMD Seeder business object determines the service provider and measuring component for the measurement (based on attributes supplied in the incoming reading, such as device ID, external reference ID, etc.). This is performed by the "Derive Service Provider and Measuring Component" pre-processing algorithm (D1-DER-SPRMC).

If the service provider is not specified on the device, the algorithm tries to derive it from the device type. Otherwise, it attempts to derive the service provider from the measurement cycle route from the service point at which the device is installed (if available).

The IMD Seeder also ensures that the Start and End Date/Time fields on the initial measurement are populated, deriving them from the incoming reading if necessary. This step is performed by the "Derive IMD Date/Time Values" pre-processing algorithm (D1-VALDR-INP).

Critical Validations

The IMD Seeder also performs a series of critical validations to ensure that the incokming reading contains valid data. These critical validations include validating that the device identifier supplied is valid and exists in the system, and performing Undercount and Overcount checks for interval readings.

•

Device Identifier : Device identifier checks validate that the device identifier provided with the measurement is valid. Device identifiers can include serial number, badge number, channel ID, etc.

•

Undercount : An undercount occurs when an interval initial measurement contains fewer interval values than approrpriate based on the interval size (or seconds-per-interval, or SPI) and the Start and End Date/Time values. For example, if an initial measurement has an interval size of one hour (or an SPI of 3600), and a Start Date/Time is October 27, 2011 and End Date/Time of October 28, 2011 (a total duration of 1 day), it should contain 24 interval values. If it contained less than 24 interval values, it could consitute an undercount.

•

Overcount : An overcount occurs when an interval initial measurement contains more interval values than approrpriate based on the interval size (or seconds-per-interval, or SPI) and the Start and End Date/Time values. For example, if an initial measurement has an interval size of one hour (or an SPI of 3600), and a Start Date/Time is October 27, 2011 and End Date/Time of October 28, 2011 (a total duration of 1 day), it should contain 24 interval values. If it contained more than 24 interval values, it could consitute an overcount.

If an incoming interval initial measurement contains either an invalid device identifier, an undercount, or an overcount, the measurement is rejected, and an instance of the IMD Seeder business object is created. Undercount and Overcount checks are performed by the "Perform Date/Time Adjustments and Undercount/Overcount Check" pre-processing algorithm (D1-DODTTMADJ).

Time Zone Translation

If your organization receives initial measurement from a source that provides its data in a different time zone than the one in which the data will be stored in Oracle Utilities Meter Data Management, a translation can be performed to translate the time zone from an external time zone identifier to one configured within the application. This translation is defined via the Head-End Time Zone to Standard Mapping extendable lookup.

Validation, Editing, and Estimation

Once received into the system, initial measurements are subject to validation, editing, and estimation. This process involves the following:

•

Validation : Validates that the initial measurement data is within expected tolerances, and is correct

•

Editing : If the initial measurement data is wrong in some way, the data can be automatically changed.

•

Estimation : If initial measurement data is incomplete (for example, if one or more interval values within an interval measurement are missing), missing values can be automatically estimated.

As noted above, the values recorded in an initial measurement can change during the validation, editing, and estimation processing, and exceptions can be raised if initial measurements are wrong in some way (such as out-of-tolerance quantities, incorrect values, etc.).

Note : The validation, editing, and estimation process is referred to as VEE, and is described in more detail in a later chapter.

Skipping VEE Processing - High Quality Check for Interval Initial Measurements

Execution of VEE rules is performed by an Enter algorithm on the "VEE Complete" state of the initial measurement business object. For interval initial measurements, the "High Quality Check - Vector Band Based" (D1-HIGHQUALV) algorithm can be used to skip VEE processing and transition the initial measurement directly to the "Finalized" state.

This algorithm checks whether the intervals within an initial measurement are considered to be of "high quality" (defined below), and if they are considered "high quality", the algorithm transitions the current initial measurement directly to the "Finalized" state.

An interval initial measurement is considered to be of "high quality" if the following conditions are met:

•

There are no missing intervals in the initial measurement

•

All interval values are within a range that extends above and below final interval values for the corresponding intervals from the previous reading. The range is defined by the "Low Tolerance" and "High Tolerance" algorithm parameters. These parameters define mutipliers that are applied to the corresponding interval from the previous reading. The "Low Tolerance" is subtracted from the previous reading’s final measurement, and the "High Tolerance" is added the the previous reading’s final measurement to define the range within which each interval must fall.

For example, if the previous reading’s final measurement value at 1:00 AM was 20, and the "Low Tolerance" parameter is set to 0.2 and the "High Tolerance" parameter is set to 0.25, the initial measurement’s value at 1:00 AM must be between between 16 (20 - 0.2*20) and 25 (20 + 0.25*20).

•

All intervals have a condition code that falls between the range defined by the "Default Bottom Range Condition Value" and "Default Top Range Condition Value" algorithm parameters.

If the initial measurement fails any part of the high quality assessment, the routine simply exits.

Pre VEE and Post VEE Quantities

Initial measurement data contains both the original and final versions of the quantities recorded by the measuring component.

•

Pre VEE quantities are consumption values derived from the measurements recorded by the head-end system or meter reader.

•

Post VEE quantities are the "final" values, after VEE processing.

Pre VEE and Post VEE quantities in an initial measurement often differ based on a number of conditions, including:

1.

The measuring component has a multiplier other than 1.

In this case, the Post VEE value is equal to the Pre VEE value times the multiplier.

2.

The installation event has a constant other than 1.

In this case, the Post VEE value is equal to the Pre VEE value times the installation constant.

3.

VEE rules have changed the quantities because they are missing or obviously wrong

In this, the Pre VEE values are adjusted based on the specifics of the VEE rules applied to the initial measurement to create the Post VEE values

4.

Manual changes by a user.

Condition Codes

In addition to recorded consumption values, measurements also have condition codes, used to indicate the source and quality of a measurement. For example:

•

Regularly recorded measurements might have a condition code of "Regular"

•

Missing measurements might have a condition code of "Missing"

•

Estimated measurements might have a condition code of "External Estimated" or "System Estimated" based on where the estimation was performed.

Both Pre VEE and Post VEE values have their own condition code, which can also change during VEE processing. For example, consider the following sample measurements from an interval measuring component:

Date / Time

Pre VEE Value

Pre VEE Condition

Post VEE Value

Post VEE Condition

01/01/2010 3:00 PM

14.678

Regular

15.1

Regular

01/01/2010 4:00 PM

Missing

20

Estimated

01/01/2010 5:00 PM

13.12

Regular

13.41

Regular

01/01/2010 6:00 PM

150.12

Regular

14.12

Estimated

For the 4:00 PM interval, note the Pre VEE condition indicates the interval is missing and the Post VEE condition highlights that it was estimated.

For the 6:00 PM interval (containing a spike, or an interval with conspicuously high usage relative to surrounding intervals), note that the system head-end (the system that recorded the measurement) indicated the interval value was fine (Pre VEE is regular), but the VEE process smoothed it, and set the Post VEE condition to "Estimated."

Condition Codes Extendable Lookup

Condition codes are defined in the Measurement Condition extendable lookup (D1-MeasurementConditionLookup). Base package condition codes delivered in this extendable lookup include the following:

Condition Code (Value)

Description

100000

No Read - System

101000

No Read - Outage

201000

Missing

301000

System Estimate

401000

External Estimate

402000

Office Estimate

501000

Regular

901000

Super

Additional condition codes can be added to this extendable lookup to meet requirements specific to individual implementations. Gaps between the base package condition code values allow custom condition codes to be added that represent data with conditions that fall between the base package conditions. For example, a condition code to indicate that the measurement was estimated based on partially incomplete data (and is considered to be of worse quality than "System Estimate", but better than "Missing") would fall somewhere between 201000 and 301000.

As a general rule, condition codes used to represent bad data or error conditions should be smaller than condition codes used to represent good data.’

Reader Remarks and Scalar Measurements

Initial measurements for manually-read scalar meters can create reader remarks. Reader remarks are a specific type of device event used to capture and/or record specific events or circumstances encountered when a meter reader is manually reading scalar meters.

Reader remark types are submitted with scalar initial measurements when received from a head-end system or meter read collection system. Reader remarks are NOT uploaded along with other device events. Reader remarks are ALWAYS associated with a scalar initial measurement.

Understanding Reader Remark Processing

This section provides an overview of the process that takes place when reader remarks are received within a scalar measurement. For each step in the process, the table below provides a brief description of the processing that takes place, and lists the specific objects used by the Service and Measurement Data Foundation

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

Step

Process

Service and Measurement Data Foundation Objects

1.

The system receives an initial measurement from a manually-read scalar device that contains one or more reader remark types.

The base package "Initial Load IMD (Scalar)" (D1-IntialLoadIMDScalar) business object supports inclusion of one or more reader remark types.

2.

When the initial measurement enters the Finalized state, an Enter algorithm creates a reader remark for each reader remark type included in the initial measurement.

Note: Creation of reader remarks does NOT make use of device event mapping extendable lookups.

Algorithm: D1-CRE-RR (Create Reader Remark)

3.

Reader remarks begin in the Pending state. They are transitioned to the Execute state either manually or via batch processing.

The Execute state contains a number of Enter algorithms that perform the following

•

Determine if the reader remark is eligible for processing, based on the "Eligible for Processing" flag on the reader remark type

•

Create a To Do Entry based on the "To Do Type" and "To Do Role" defined on the reader remark type

•

Create a service issue monitor based on the service issue monitor specified on the reader remark type

•

Send the reader remark to subscribing systems

Batch Control: D1-DVEVT (Device Event MO Periodic Monitor Process)

Algorithm: D1-RR-ELIG (Reader Remark Eligibility)

Algorithm: D1-CRE-RR-TD (Create To Do Entry for Reader Remark)

Algorithm: D1-DVCEVTSIM (Create Service Issue Monitor for Reader Remark)

Algorithm: D1-RRSENDSUB (Send to Subscribers for Reader Remark)

Sending Reader Remarks to Subscribing Systems

Reader remarks can be passed onto to other subscribing systems such as a customer information system (such as Oracle Utilities Customer Care and Billing), an outage system (such as Oracle Utilities Network Management System), or some other application.

Reader remarks are sent to subscribing systems when they enter the Execute state. An Enter algorithm (D1-RRSENDSUB /Send to Subscribers for Reader Remark in the base package) determines which service providers (external systems) are interested in receiving the current reader remark based upon its type and category, finds the processing method for each, and processes the device event accordingly.

The means of sending reader remark information to subscribing systems is defined in the "How to Send Device Event Related Information" processing method for the service provider representing the subscribing system. Reader remark information can be sent via outbound communication business object, outbound communication, or batch process.

The method for sending device events to subscribing systems (business object, outbound message, or batch process) is defined for the "Reader Remark" device event category, and can be overridden for individual reader remark types (including the ability to exclude specific reader remark types. In addition, a default event processing method can be also be configured that applies when methods of transmission aren't specified at the individual category level.

The "Subscribe to Device Event" business service is used to process reader remark subscription requests, and allow external applications to manage the categories of events they receive.

Reader Remarks and Service Issue Monitors

Like other device events, reader remarks can create service issue monitors. See Service Issue Monitors and Service Investigative Orders in Chapter 8: Device Communication and Device Events for more information about service issue monitors.

Subtractive Measuring Components

Initial measurement data for subtractive measuring components (such as most scalar measuring components) also typically contain start and stop readings in addition to Pre and Post VEE usage. For example, a set of initial measurements for s subtractive scalar measuring component might look like the following:

Date / Time

Start Reading

Stop Reading

Pre VEE Usage

Pre VEE Condition

Post VEE Value

Post VEE Usage

01/01/2010 3:00 PM

0

1500

1500

Regular

1515

Regular

02/2/2010 4:11 PM

1500

2100

600

Regular

606

Regular

03/03/2010 5:22 PM

2100

2900

800

Regular

808

Regular

04/01/2010 1:00 PM

2900

3500

600

Regular

606

Regular

Rollover Calculations

Subtractive measuring components can "rollover" when the reading exceeds the maximum value based on the number of dials. For example, a register with a 4 dials can record values up to 9999 before rolling over to 0000. When this occurs, consumption is calculated based on the following attributes and calculated values.

•

Rollover Threshold is the percentage of the measuring component's dial capacity at which measurements for measuring components of this type are considered to have rolled over. Dial capacity is the largest value that can be recorded for the measuring component, based on the measuring component's number of dials. For example, a measuring component with 5 dials has a dial capacity of 99999.

•

MaxDialCapacity is the maximum value for the number of dials, rounded up to the next whole multiple of 10 (or 10 raised to the power of the number of dials). For example, for a register with 4 dials, the MaxDialValue is 10000.

•

MaxAcceptableDifference is the maximum acceptable consumption that can be recorded for the register. This is equal to the MaxDialCapacity multiplied by the rollover threshold. For example, the MaxAcceptableDifference for a register with 4 dials and a rollover threshold of 90% would be 9000. If the consumption is greater than this value, the initial measurement is transitioned to the Error state.

•

Difference : The difference between the Stop Reading and Start Reading, obtained by subtracting the Start Reading from the Stop Reading. If the Difference is less than zero (<0), then add the MaxDialCapacity to calculate Rollover.

•

Rollover : The adjusted consumption for a reading on a register that has rolled over. Only applicable if the Difference (Stop Reading - Start Reading) is less than zero (<0).

•

Consumption : The calculated consumption for the reading, equal to either the Difference or Rollover. If the Difference is greater than or equal to zero, consumption is equal to the Difference. If the Difference is less than zero (<0), and the Rollover is less than or equal to the MaxAcceptableDifference, the consumption is equal to the Rollover.

Example : Consider an initial measurement with the following attributes:

•

Number of Dials: 4

•

Rollover Threshold: 90 (%)

•

Start Reading: 8900

•

Stop Reading: 0500

For this reading,

MaxDialCapacity = 10000

MaxAcceptableDifference = 9000 (10000 * .90)

Difference = 0500 (Stop Reading) - 8900 (Start Reading) or -8400

Rollover = 10000 (MaxDialCapacity) + -8400 (Difference) or 1600

Consumption is equal to 1600 (Rollover).

Estimated Initial Measurements

Over the course of time, it may happen that the system will not receive usage for a device for some period of time. When the system detects that a measuring component is missing final measurements, it can creates a initial measurement via estimation. This type of initial measurement is referred to as an estimated initial measurement (as opposed to an Initial Load or Manual initial measurement).

At a high-level, the estimation process is as follows:

•

Missing Measurements are detected by a "Period Estimation" system event algorithm on the measuring component business object

•

Estimated initial measurements are created for the "missing" time period by the "Period Estimation" system event algorithm on the measuring component business object

•

Values and consumption for the estimated initial measurements are calculated by "estimation" VEE rules.

It’s important to note that the processes that detect missing measurements do NOT themselves estimate consumption. Rather, these detection processes simply create an initial measurement and let the estimation VEE rules estimate the consumption for the initial measurement.

Detecting Missing Measurements

The detection of missing measurements occurs at different points in time for interval and scalar measuring components:

•

For interval measuring components, a dedicated batch process exists to initiate creation of estimated initial measurements

•

For manually read scalar measuring components, a usage calculation rule creates the initial measurement if it cannot find a measurement and it has been given permission to estimate. (Note: the information that follows applies primarily to interval measuring components).

The batch process that detects missing consumption for interval measuring components uses two elements on interval measurinng component type:

•

Hours Before Estimation : the number of hours after the End Date and Time of the most recent measurement that must pass before the measuring component is considered due for estimation. For example, if set to 72 hours, estimation will only take place 72 hours after the End Date and Time of the latest measurement.

•

Number of Hours to Estimate : the number of hours of measurement data that are estimated when estimation is performed for the measuring component.

If a measuring component has contiguous final measurements on/after a date and time equal to the current date/time minus the "Hours Before Estimate" value, the measuring component is not estimated.

If the measuring component does NOT have contiguous final measurements on/after a date and time equal to the current date/time minus the "Hours Before Estimate" value, the measuring component is estimated. If the measuring component is subject to estimation, measurements will be estimated through the a date and time equal to the current date/time minus the (Hours Before Estimation - Number of Hours to Estimate).

The following examples illustrate how the system determines if estimation should take place. These examples are all assume a measuring component whose measuring component type specifies an "Hours Before Estimation" of 72 (3 days) and a "Number of Hours to Estimate" of 24 (1 day).

Example 1 : On January 9, if there is contiguous consumption through January 7, estimation would not occur because consumption exists after January 6 (3 days prior to January 9). The diagram below illustrates this example:

Example 2 : On Janury 9 if contiguous consumption existed through January 2, estimation would take place because consumption does not exist through January 6 (3 days prior to January 9). In this example, consumption would be estimated for missing intervals from January 2 through January 7 (January 9 minus 48 hours (Hours Before Estimation minus Number of Hours to Estimate). Note that this assumes that period estimation had NOT been run after January 5. The diagram below illustrates this example:

Example 3 : On Janury 9 if contiguous consumption existed through January 2 and for January 5 (but NOT for January 3-4 or 6-7), two initial measurements would be created, one for January 3-4, and another for January 6-7. The diagram below illustrates this example:

Estimation Algorithms

Estimation for interval measuring components is detected and initiated by two algorithms, one on the device business object, and the other on the measuring component business object.

Devices whose measuring components are subject to periodic estimation (in most cases, interval measuring components) have a "Period Estimation" Monitor algorithm (D1-PERESTM) on their Active state. This monitoring algorithm retrieves the device's measuring component and invokes the algorithm on the "Periodic Estimation" system event on the measuring component business object. Note - the device monitoring algorithm can be configured to look at device configurations from a number of days in the past defined by an algorithm parameter. The base package includes this algorithm on the Active state of the Smart Meter (D1-SmartMeter) device business object. The "Periodic Estimation" monitor algorithm can be triggered by the "Smart Meter State Monitor Process" batch process (D1-SMMTR).

The "Periodic Estimation" System Event algorithm determines if a measuring component is missing final measurements (as described above), and if final measurements are missing, estimates initial measurements and/or creates a To Do Entry. In the base package, this algorithm is the "Create Initial Measurement and To Do Entry" algorithm (D1-CRIMTODO). Algorithm parameters can specify if an initial measurement is to be created, if an To Do Entry is to be created, and the To Do Type and Role (if applicable) for any To Do entries created. The base package includes this algorithm on the Period Estimation system event state of the Interval Channel (D1-IntervalChannel) measuring component business object.

Estimation Calculations

When new estimated initial measurements are created (for either interval or scalar measuring components), the Pre-VEE and Post-VEE values are initially set to zero. When the initial measurement enters the "VEE Complete" state, the VEE rules within the VEE group defined for the "Estimation" VEE role (defined by the "VEE Group For Estimation" field on the measuring component) calculate values and consumption for the initial measurement.

Note that the VEE rules used in this process can also include validation rules that perform validation on the estimated values and consumption. For example, the "estimation" VEE group might contain rules to estimate interval values from a profile, and then perform a sum check to validate the resulting interval measurement against measurements from a consumption reference measuring component. In this example, the sum check validation would be configured to be applied after the interval profile estimation.

Estimated initial measurements are created using "estimation" initial measurement business objects. The base package includes the Estimation IMD (Interval) and Estimation IMD (Scalar) business objects (D1-EstimationIMDInterval or D1-EstimationIMDScalar, respectively).

Initial Measurement Data

Measurements read from a measuring component are referred to as "initial measurement data" (or initial measurements) and are used to record how much of the quantity (defined by UOM, TOU, and SQI) measured by the measuring component was consumed.

Initial measurement data for scalar measuring components contain a single "reading" or value, while initial measurement data for interval measuring components can contain multiple readings, one for each interval that falls between the start time and stop time of the measurement.

At a simple level, initial measurement data goes through the following process:

1.

Initial measurements are loaded into the system.

2.

Initial measurement data is validated, edited, and estimated.

3.

Initial measurements are converted into final measurements.

4.

Final measurements are used to calculate usage (bill determinants, etc.).

Creating Initial Measurements

The IMD Seeder business object (D1-IMDSeeder) is used to create initial measurements (via instantiating initial measurement business objects), based on the head-end system sending the measurement. The "Initial Measurement Creation" processing method defined for the head-end system service provider defines the specific type of initial measurement to create. If for some reason an initial measurement can’t be created, an instance of the IMD Seeder business object is created to allow tracking of the error (and once the error is resolved, the IMD Seeder instance can be reprocessed.

The IMD Seeder business object determines the service provider and measuring component for the measurement (based on attributes supplied in the incoming reading, such as device ID, external reference ID, etc.). This is performed by the "Derive Service Provider and Measuring Component" pre-processing algorithm (D1-DER-SPRMC).

If the service provider is not specified on the device, the algorithm tries to derive it from the device type. Otherwise, it attempts to derive the service provider from the measurement cycle route from the service point at which the device is installed (if available).

The IMD Seeder also ensures that the Start and End Date/Time fields on the initial measurement are populated, deriving them from the incoming reading if necessary. This step is performed by the "Derive IMD Date/Time Values" pre-processing algorithm (D1-VALDR-INP).

Critical Validations

The IMD Seeder also performs a series of critical validations to ensure that the incokming reading contains valid data. These critical validations include validating that the device identifier supplied is valid and exists in the system, and performing Undercount and Overcount checks for interval readings.

•

Device Identifier : Device identifier checks validate that the device identifier provided with the measurement is valid. Device identifiers can include serial number, badge number, channel ID, etc.

•

Undercount : An undercount occurs when an interval initial measurement contains fewer interval values than approrpriate based on the interval size (or seconds-per-interval, or SPI) and the Start and End Date/Time values. For example, if an initial measurement has an interval size of one hour (or an SPI of 3600), and a Start Date/Time is October 27, 2011 and End Date/Time of October 28, 2011 (a total duration of 1 day), it should contain 24 interval values. If it contained less than 24 interval values, it could consitute an undercount.

•

Overcount : An overcount occurs when an interval initial measurement contains more interval values than approrpriate based on the interval size (or seconds-per-interval, or SPI) and the Start and End Date/Time values. For example, if an initial measurement has an interval size of one hour (or an SPI of 3600), and a Start Date/Time is October 27, 2011 and End Date/Time of October 28, 2011 (a total duration of 1 day), it should contain 24 interval values. If it contained more than 24 interval values, it could consitute an overcount.

If an incoming interval initial measurement contains either an invalid device identifier, an undercount, or an overcount, the measurement is rejected, and an instance of the IMD Seeder business object is created. Undercount and Overcount checks are performed by the "Perform Date/Time Adjustments and Undercount/Overcount Check" pre-processing algorithm (D1-DODTTMADJ).

Time Zone Translation

If your organization receives initial measurement from a source that provides its data in a different time zone than the one in which the data will be stored in Oracle Utilities Meter Data Management, a translation can be performed to translate the time zone from an external time zone identifier to one configured within the application. This translation is defined via the Head-End Time Zone to Standard Mapping extendable lookup.

Validation, Editing, and Estimation

Once received into the system, initial measurements are subject to validation, editing, and estimation. This process involves the following:

•

Validation : Validates that the initial measurement data is within expected tolerances, and is correct

•

Editing : If the initial measurement data is wrong in some way, the data can be automatically changed.

•

Estimation : If initial measurement data is incomplete (for example, if one or more interval values within an interval measurement are missing), missing values can be automatically estimated.

As noted above, the values recorded in an initial measurement can change during the validation, editing, and estimation processing, and exceptions can be raised if initial measurements are wrong in some way (such as out-of-tolerance quantities, incorrect values, etc.).

Note : The validation, editing, and estimation process is referred to as VEE, and is described in more detail in a later chapter.

Skipping VEE Processing - High Quality Check for Interval Initial Measurements

Execution of VEE rules is performed by an Enter algorithm on the "VEE Complete" state of the initial measurement business object. For interval initial measurements, the "High Quality Check - Vector Band Based" (D1-HIGHQUALV) algorithm can be used to skip VEE processing and transition the initial measurement directly to the "Finalized" state.

This algorithm checks whether the intervals within an initial measurement are considered to be of "high quality" (defined below), and if they are considered "high quality", the algorithm transitions the current initial measurement directly to the "Finalized" state.

An interval initial measurement is considered to be of "high quality" if the following conditions are met:

•

There are no missing intervals in the initial measurement

•

All interval values are within a range that extends above and below final interval values for the corresponding intervals from the previous reading. The range is defined by the "Low Tolerance" and "High Tolerance" algorithm parameters. These parameters define mutipliers that are applied to the corresponding interval from the previous reading. The "Low Tolerance" is subtracted from the previous reading’s final measurement, and the "High Tolerance" is added the the previous reading’s final measurement to define the range within which each interval must fall.

For example, if the previous reading’s final measurement value at 1:00 AM was 20, and the "Low Tolerance" parameter is set to 0.2 and the "High Tolerance" parameter is set to 0.25, the initial measurement’s value at 1:00 AM must be between between 16 (20 - 0.2*20) and 25 (20 + 0.25*20).

•

All intervals have a condition code that falls between the range defined by the "Default Bottom Range Condition Value" and "Default Top Range Condition Value" algorithm parameters.

If the initial measurement fails any part of the high quality assessment, the routine simply exits.

Pre VEE and Post VEE Quantities

Initial measurement data contains both the original and final versions of the quantities recorded by the measuring component.

•

Pre VEE quantities are consumption values derived from the measurements recorded by the head-end system or meter reader.

•

Post VEE quantities are the "final" values, after VEE processing.

Pre VEE and Post VEE quantities in an initial measurement often differ based on a number of conditions, including:

1.

The measuring component has a multiplier other than 1.

In this case, the Post VEE value is equal to the Pre VEE value times the multiplier.

2.

The installation event has a constant other than 1.

In this case, the Post VEE value is equal to the Pre VEE value times the installation constant.

3.

VEE rules have changed the quantities because they are missing or obviously wrong

In this, the Pre VEE values are adjusted based on the specifics of the VEE rules applied to the initial measurement to create the Post VEE values

4.

Manual changes by a user.

Condition Codes

In addition to recorded consumption values, measurements also have condition codes, used to indicate the source and quality of a measurement. For example:

•

Regularly recorded measurements might have a condition code of "Regular"

•

Missing measurements might have a condition code of "Missing"

•

Estimated measurements might have a condition code of "External Estimated" or "System Estimated" based on where the estimation was performed.

Both Pre VEE and Post VEE values have their own condition code, which can also change during VEE processing. For example, consider the following sample measurements from an interval measuring component:

Date / Time

Pre VEE Value

Pre VEE Condition

Post VEE Value

Post VEE Condition

01/01/2010 3:00 PM

14.678

Regular

15.1

Regular

01/01/2010 4:00 PM

Missing

20

Estimated

01/01/2010 5:00 PM

13.12

Regular

13.41

Regular

01/01/2010 6:00 PM

150.12

Regular

14.12

Estimated

For the 4:00 PM interval, note the Pre VEE condition indicates the interval is missing and the Post VEE condition highlights that it was estimated.

For the 6:00 PM interval (containing a spike, or an interval with conspicuously high usage relative to surrounding intervals), note that the system head-end (the system that recorded the measurement) indicated the interval value was fine (Pre VEE is regular), but the VEE process smoothed it, and set the Post VEE condition to "Estimated."

Condition Codes Extendable Lookup

Condition codes are defined in the Measurement Condition extendable lookup (D1-MeasurementConditionLookup). Base package condition codes delivered in this extendable lookup include the following:

Condition Code (Value)

Description

100000

No Read - System

101000

No Read - Outage

201000

Missing

301000

System Estimate

401000

External Estimate

402000

Office Estimate

501000

Regular

901000

Super

Additional condition codes can be added to this extendable lookup to meet requirements specific to individual implementations. Gaps between the base package condition code values allow custom condition codes to be added that represent data with conditions that fall between the base package conditions. For example, a condition code to indicate that the measurement was estimated based on partially incomplete data (and is considered to be of worse quality than "System Estimate", but better than "Missing") would fall somewhere between 201000 and 301000.

As a general rule, condition codes used to represent bad data or error conditions should be smaller than condition codes used to represent good data.’

Reader Remarks and Scalar Measurements

Initial measurements for manually-read scalar meters can create reader remarks. Reader remarks are a specific type of device event used to capture and/or record specific events or circumstances encountered when a meter reader is manually reading scalar meters.

Reader remark types are submitted with scalar initial measurements when received from a head-end system or meter read collection system. Reader remarks are NOT uploaded along with other device events. Reader remarks are ALWAYS associated with a scalar initial measurement.

Understanding Reader Remark Processing

This section provides an overview of the process that takes place when reader remarks are received within a scalar measurement. For each step in the process, the table below provides a brief description of the processing that takes place, and lists the specific objects used by the Service and Measurement Data Foundation

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

Step

Process

Service and Measurement Data Foundation Objects

1.

The system receives an initial measurement from a manually-read scalar device that contains one or more reader remark types.

The base package "Initial Load IMD (Scalar)" (D1-IntialLoadIMDScalar) business object supports inclusion of one or more reader remark types.

2.

When the initial measurement enters the Finalized state, an Enter algorithm creates a reader remark for each reader remark type included in the initial measurement.

Note: Creation of reader remarks does NOT make use of device event mapping extendable lookups.

Algorithm: D1-CRE-RR (Create Reader Remark)

3.

Reader remarks begin in the Pending state. They are transitioned to the Execute state either manually or via batch processing.

The Execute state contains a number of Enter algorithms that perform the following

•

Determine if the reader remark is eligible for processing, based on the "Eligible for Processing" flag on the reader remark type

•

Create a To Do Entry based on the "To Do Type" and "To Do Role" defined on the reader remark type

•

Create a service issue monitor based on the service issue monitor specified on the reader remark type

•

Send the reader remark to subscribing systems

Batch Control: D1-DVEVT (Device Event MO Periodic Monitor Process)

Algorithm: D1-RR-ELIG (Reader Remark Eligibility)

Algorithm: D1-CRE-RR-TD (Create To Do Entry for Reader Remark)

Algorithm: D1-DVCEVTSIM (Create Service Issue Monitor for Reader Remark)

Algorithm: D1-RRSENDSUB (Send to Subscribers for Reader Remark)

Sending Reader Remarks to Subscribing Systems

Reader remarks can be passed onto to other subscribing systems such as a customer information system (such as Oracle Utilities Customer Care and Billing), an outage system (such as Oracle Utilities Network Management System), or some other application.

Reader remarks are sent to subscribing systems when they enter the Execute state. An Enter algorithm (D1-RRSENDSUB /Send to Subscribers for Reader Remark in the base package) determines which service providers (external systems) are interested in receiving the current reader remark based upon its type and category, finds the processing method for each, and processes the device event accordingly.

The means of sending reader remark information to subscribing systems is defined in the "How to Send Device Event Related Information" processing method for the service provider representing the subscribing system. Reader remark information can be sent via outbound communication business object, outbound communication, or batch process.

The method for sending device events to subscribing systems (business object, outbound message, or batch process) is defined for the "Reader Remark" device event category, and can be overridden for individual reader remark types (including the ability to exclude specific reader remark types. In addition, a default event processing method can be also be configured that applies when methods of transmission aren't specified at the individual category level.

The "Subscribe to Device Event" business service is used to process reader remark subscription requests, and allow external applications to manage the categories of events they receive.

Reader Remarks and Service Issue Monitors

Like other device events, reader remarks can create service issue monitors. See Service Issue Monitors and Service Investigative Orders in Chapter 8: Device Communication and Device Events for more information about service issue monitors.

Subtractive Measuring Components

Initial measurement data for subtractive measuring components (such as most scalar measuring components) also typically contain start and stop readings in addition to Pre and Post VEE usage. For example, a set of initial measurements for s subtractive scalar measuring component might look like the following:

Date / Time

Start Reading

Stop Reading

Pre VEE Usage

Pre VEE Condition

Post VEE Value

Post VEE Usage

01/01/2010 3:00 PM

0

1500

1500

Regular

1515

Regular

02/2/2010 4:11 PM

1500

2100

600

Regular

606

Regular

03/03/2010 5:22 PM

2100

2900

800

Regular

808

Regular

04/01/2010 1:00 PM

2900

3500

600

Regular

606

Regular

Rollover Calculations

Subtractive measuring components can "rollover" when the reading exceeds the maximum value based on the number of dials. For example, a register with a 4 dials can record values up to 9999 before rolling over to 0000. When this occurs, consumption is calculated based on the following attributes and calculated values.

•

Rollover Threshold is the percentage of the measuring component's dial capacity at which measurements for measuring components of this type are considered to have rolled over. Dial capacity is the largest value that can be recorded for the measuring component, based on the measuring component's number of dials. For example, a measuring component with 5 dials has a dial capacity of 99999.

•

MaxDialCapacity is the maximum value for the number of dials, rounded up to the next whole multiple of 10 (or 10 raised to the power of the number of dials). For example, for a register with 4 dials, the MaxDialValue is 10000.

•

MaxAcceptableDifference is the maximum acceptable consumption that can be recorded for the register. This is equal to the MaxDialCapacity multiplied by the rollover threshold. For example, the MaxAcceptableDifference for a register with 4 dials and a rollover threshold of 90% would be 9000. If the consumption is greater than this value, the initial measurement is transitioned to the Error state.

•

Difference : The difference between the Stop Reading and Start Reading, obtained by subtracting the Start Reading from the Stop Reading. If the Difference is less than zero (<0), then add the MaxDialCapacity to calculate Rollover.

•

Rollover : The adjusted consumption for a reading on a register that has rolled over. Only applicable if the Difference (Stop Reading - Start Reading) is less than zero (<0).

•

Consumption : The calculated consumption for the reading, equal to either the Difference or Rollover. If the Difference is greater than or equal to zero, consumption is equal to the Difference. If the Difference is less than zero (<0), and the Rollover is less than or equal to the MaxAcceptableDifference, the consumption is equal to the Rollover.

Example : Consider an initial measurement with the following attributes:

•

Number of Dials: 4

•

Rollover Threshold: 90 (%)

•

Start Reading: 8900

•

Stop Reading: 0500

For this reading,

MaxDialCapacity = 10000

MaxAcceptableDifference = 9000 (10000 * .90)

Difference = 0500 (Stop Reading) - 8900 (Start Reading) or -8400

Rollover = 10000 (MaxDialCapacity) + -8400 (Difference) or 1600

Consumption is equal to 1600 (Rollover).

Estimated Initial Measurements

Over the course of time, it may happen that the system will not receive usage for a device for some period of time. When the system detects that a measuring component is missing final measurements, it can creates a initial measurement via estimation. This type of initial measurement is referred to as an estimated initial measurement (as opposed to an Initial Load or Manual initial measurement).

At a high-level, the estimation process is as follows:

•

Missing Measurements are detected by a "Period Estimation" system event algorithm on the measuring component business object

•

Estimated initial measurements are created for the "missing" time period by the "Period Estimation" system event algorithm on the measuring component business object

•

Values and consumption for the estimated initial measurements are calculated by "estimation" VEE rules.

It’s important to note that the processes that detect missing measurements do NOT themselves estimate consumption. Rather, these detection processes simply create an initial measurement and let the estimation VEE rules estimate the consumption for the initial measurement.

Detecting Missing Measurements

The detection of missing measurements occurs at different points in time for interval and scalar measuring components:

•

For interval measuring components, a dedicated batch process exists to initiate creation of estimated initial measurements

•

For manually read scalar measuring components, a usage calculation rule creates the initial measurement if it cannot find a measurement and it has been given permission to estimate. (Note: the information that follows applies primarily to interval measuring components).

The batch process that detects missing consumption for interval measuring components uses two elements on interval measurinng component type:

•

Hours Before Estimation : the number of hours after the End Date and Time of the most recent measurement that must pass before the measuring component is considered due for estimation. For example, if set to 72 hours, estimation will only take place 72 hours after the End Date and Time of the latest measurement.

•

Number of Hours to Estimate : the number of hours of measurement data that are estimated when estimation is performed for the measuring component.

If a measuring component has contiguous final measurements on/after a date and time equal to the current date/time minus the "Hours Before Estimate" value, the measuring component is not estimated.

If the measuring component does NOT have contiguous final measurements on/after a date and time equal to the current date/time minus the "Hours Before Estimate" value, the measuring component is estimated. If the measuring component is subject to estimation, measurements will be estimated through the a date and time equal to the current date/time minus the (Hours Before Estimation - Number of Hours to Estimate).

The following examples illustrate how the system determines if estimation should take place. These examples are all assume a measuring component whose measuring component type specifies an "Hours Before Estimation" of 72 (3 days) and a "Number of Hours to Estimate" of 24 (1 day).

Example 1 : On January 9, if there is contiguous consumption through January 7, estimation would not occur because consumption exists after January 6 (3 days prior to January 9). The diagram below illustrates this example:

Example 2 : On Janury 9 if contiguous consumption existed through January 2, estimation would take place because consumption does not exist through January 6 (3 days prior to January 9). In this example, consumption would be estimated for missing intervals from January 2 through January 7 (January 9 minus 48 hours (Hours Before Estimation minus Number of Hours to Estimate). Note that this assumes that period estimation had NOT been run after January 5. The diagram below illustrates this example:

Example 3 : On Janury 9 if contiguous consumption existed through January 2 and for January 5 (but NOT for January 3-4 or 6-7), two initial measurements would be created, one for January 3-4, and another for January 6-7. The diagram below illustrates this example:

Estimation Algorithms

Estimation for interval measuring components is detected and initiated by two algorithms, one on the device business object, and the other on the measuring component business object.

Devices whose measuring components are subject to periodic estimation (in most cases, interval measuring components) have a "Period Estimation" Monitor algorithm (D1-PERESTM) on their Active state. This monitoring algorithm retrieves the device's measuring component and invokes the algorithm on the "Periodic Estimation" system event on the measuring component business object. Note - the device monitoring algorithm can be configured to look at device configurations from a number of days in the past defined by an algorithm parameter. The base package includes this algorithm on the Active state of the Smart Meter (D1-SmartMeter) device business object. The "Periodic Estimation" monitor algorithm can be triggered by the "Smart Meter State Monitor Process" batch process (D1-SMMTR).

The "Periodic Estimation" System Event algorithm determines if a measuring component is missing final measurements (as described above), and if final measurements are missing, estimates initial measurements and/or creates a To Do Entry. In the base package, this algorithm is the "Create Initial Measurement and To Do Entry" algorithm (D1-CRIMTODO). Algorithm parameters can specify if an initial measurement is to be created, if an To Do Entry is to be created, and the To Do Type and Role (if applicable) for any To Do entries created. The base package includes this algorithm on the Period Estimation system event state of the Interval Channel (D1-IntervalChannel) measuring component business object.

Estimation Calculations

When new estimated initial measurements are created (for either interval or scalar measuring components), the Pre-VEE and Post-VEE values are initially set to zero. When the initial measurement enters the "VEE Complete" state, the VEE rules within the VEE group defined for the "Estimation" VEE role (defined by the "VEE Group For Estimation" field on the measuring component) calculate values and consumption for the initial measurement.

Note that the VEE rules used in this process can also include validation rules that perform validation on the estimated values and consumption. For example, the "estimation" VEE group might contain rules to estimate interval values from a profile, and then perform a sum check to validate the resulting interval measurement against measurements from a consumption reference measuring component. In this example, the sum check validation would be configured to be applied after the interval profile estimation.

Estimated initial measurements are created using "estimation" initial measurement business objects. The base package includes the Estimation IMD (Interval) and Estimation IMD (Scalar) business objects (D1-EstimationIMDInterval or D1-EstimationIMDScalar, respectively).

Final Measurements

When an initial measurement is considered "final," that is, it has pass all VEE processing and no additional modifications or changes need to be made, it is transformed into a Final Measurement, or simply a Measurement (the terms measurement, final measurement, and final consumption all reference this same "final" measurement data).

When creating final measurements from initial measurement data:

•

Final measurements are created using Post VEE quantities

•

Each final measurement's condition is copied from the Post VEE condition

•

Initial measurements are normalized into final measurements where each final measurement is for a specific date and time.

•

Because a single initial measurement may contain many "readings," a separate final measurement is created for each interval in the initial measurement. For example, if an initial measurement contains 24 hours of 15 minute readings, 96 measurements will be created, each with a specific date and time.

Final measurements are periodically transformed into more concise and accessible usage (also known as bill determinants) for the subscribing systems. In this example, a time-of-use map is applied to the final measurements for an entire month. The usage calculation process is described in more detail in a later chapter.

Derived Values

Final measurements can record up to 10 derived values in addition to the "as measured" value. The derivation formula for each value on a final measurement is held in an algorithm and therefore can derive anything. For example, a set of measurements can adjusted or converted into other units of measure:

Date / Time

As Measured

UOM: CCF

SQI: n/a

Loss Adjusted

UOM: CCF

SQI: n/a

Thermal Units

UOM: BTU

SQI: n/a

01/01/2010 3:00 PM

10

10.1

10.11

01/01/2010 4:00 PM

15

15.15

15.165

01/01/2010 5:00 PM

10

10.1

10.11

Derived values are not reliant on consumption values, but can also come from factors, historical data, or another source.For example, measurements might be compared to "normal" usage for the usage period:

Date / Time

As Measured

UOM: CCF

SQI: n/a

Loss Adjusted

UOM: CCF

SQI: n/a

Thermal Units

UOM: BTU

SQI: n/a

Normal CCF

UOM: CCF

SQI: Normal

Percent (%) of Normal

UOM: CCF

SQI: n/a

01/01/2010 3:00 PM

10

10.1

10.11

10

100%

01/01/2010 4:00 PM

15

15.15

15.165

10

150%

01/01/2010 5:00 PM

10

10.1

10.11

10

100%

Updating Final Measurements

Final measurements can be updated if necessary. If final measurements are discovered to incorrect (for whatever reason), a new initial measurement is created to correct them. This new initial measurement contains the corrected consumption, and after the initial measurement has completed VEE processing, the existing final measurements are updated with the newly calculated consumption.

Note : The primary key on the table used to store final measurements (the Measurement table) is a combination of the measuring component ID and the date/time of the measurement. This means that it is impossible for more than one final measurement to exist for a measuring component for a given date/time.

The reason a new initial measurement must be created and completed to add or update measurements because there no user interface that allows users to directly edit final measurements.

Final Measurements

When an initial measurement is considered "final," that is, it has pass all VEE processing and no additional modifications or changes need to be made, it is transformed into a Final Measurement, or simply a Measurement (the terms measurement, final measurement, and final consumption all reference this same "final" measurement data).

When creating final measurements from initial measurement data:

•

Final measurements are created using Post VEE quantities

•

Each final measurement's condition is copied from the Post VEE condition

•

Initial measurements are normalized into final measurements where each final measurement is for a specific date and time.

•

Because a single initial measurement may contain many "readings," a separate final measurement is created for each interval in the initial measurement. For example, if an initial measurement contains 24 hours of 15 minute readings, 96 measurements will be created, each with a specific date and time.

Final measurements are periodically transformed into more concise and accessible usage (also known as bill determinants) for the subscribing systems. In this example, a time-of-use map is applied to the final measurements for an entire month. The usage calculation process is described in more detail in a later chapter.

Derived Values

Final measurements can record up to 10 derived values in addition to the "as measured" value. The derivation formula for each value on a final measurement is held in an algorithm and therefore can derive anything. For example, a set of measurements can adjusted or converted into other units of measure:

Date / Time

As Measured

UOM: CCF

SQI: n/a

Loss Adjusted

UOM: CCF

SQI: n/a

Thermal Units

UOM: BTU

SQI: n/a

01/01/2010 3:00 PM

10

10.1

10.11

01/01/2010 4:00 PM

15

15.15

15.165

01/01/2010 5:00 PM

10

10.1

10.11

Derived values are not reliant on consumption values, but can also come from factors, historical data, or another source.For example, measurements might be compared to "normal" usage for the usage period:

Date / Time

As Measured

UOM: CCF

SQI: n/a

Loss Adjusted

UOM: CCF

SQI: n/a

Thermal Units

UOM: BTU

SQI: n/a

Normal CCF

UOM: CCF

SQI: Normal

Percent (%) of Normal

UOM: CCF

SQI: n/a

01/01/2010 3:00 PM

10

10.1

10.11

10

100%

01/01/2010 4:00 PM

15

15.15

15.165

10

150%

01/01/2010 5:00 PM

10

10.1

10.11

10

100%

Updating Final Measurements

Final measurements can be updated if necessary. If final measurements are discovered to incorrect (for whatever reason), a new initial measurement is created to correct them. This new initial measurement contains the corrected consumption, and after the initial measurement has completed VEE processing, the existing final measurements are updated with the newly calculated consumption.

Note : The primary key on the table used to store final measurements (the Measurement table) is a combination of the measuring component ID and the date/time of the measurement. This means that it is impossible for more than one final measurement to exist for a measuring component for a given date/time.

The reason a new initial measurement must be created and completed to add or update measurements because there no user interface that allows users to directly edit final measurements.

Final Measurements

When an initial measurement is considered "final," that is, it has pass all VEE processing and no additional modifications or changes need to be made, it is transformed into a Final Measurement, or simply a Measurement (the terms measurement, final measurement, and final consumption all reference this same "final" measurement data).

When creating final measurements from initial measurement data:

•

Final measurements are created using Post VEE quantities

•

Each final measurement's condition is copied from the Post VEE condition

•

Initial measurements are normalized into final measurements where each final measurement is for a specific date and time.

•

Because a single initial measurement may contain many "readings," a separate final measurement is created for each interval in the initial measurement. For example, if an initial measurement contains 24 hours of 15 minute readings, 96 measurements will be created, each with a specific date and time.

Final measurements are periodically transformed into more concise and accessible usage (also known as bill determinants) for the subscribing systems. In this example, a time-of-use map is applied to the final measurements for an entire month. The usage calculation process is described in more detail in a later chapter.

Derived Values

Final measurements can record up to 10 derived values in addition to the "as measured" value. The derivation formula for each value on a final measurement is held in an algorithm and therefore can derive anything. For example, a set of measurements can adjusted or converted into other units of measure:

Date / Time

As Measured

UOM: CCF

SQI: n/a

Loss Adjusted

UOM: CCF

SQI: n/a

Thermal Units

UOM: BTU

SQI: n/a

01/01/2010 3:00 PM

10

10.1

10.11

01/01/2010 4:00 PM

15

15.15

15.165

01/01/2010 5:00 PM

10

10.1

10.11

Derived values are not reliant on consumption values, but can also come from factors, historical data, or another source.For example, measurements might be compared to "normal" usage for the usage period:

Date / Time

As Measured

UOM: CCF

SQI: n/a

Loss Adjusted

UOM: CCF

SQI: n/a

Thermal Units

UOM: BTU

SQI: n/a

Normal CCF

UOM: CCF

SQI: Normal

Percent (%) of Normal

UOM: CCF

SQI: n/a

01/01/2010 3:00 PM

10

10.1

10.11

10

100%

01/01/2010 4:00 PM

15

15.15

15.165

10

150%

01/01/2010 5:00 PM

10

10.1

10.11

10

100%

Updating Final Measurements

Final measurements can be updated if necessary. If final measurements are discovered to incorrect (for whatever reason), a new initial measurement is created to correct them. This new initial measurement contains the corrected consumption, and after the initial measurement has completed VEE processing, the existing final measurements are updated with the newly calculated consumption.

Note : The primary key on the table used to store final measurements (the Measurement table) is a combination of the measuring component ID and the date/time of the measurement. This means that it is impossible for more than one final measurement to exist for a measuring component for a given date/time.

The reason a new initial measurement must be created and completed to add or update measurements because there no user interface that allows users to directly edit final measurements.

Daylight Saving Time Support

This section describes how the Oracle Utilities Service and Measurement Data Foundation and its related products support Daylight Saving Time (DST) for measurement data, including:

•

Types of Devices

•

Date/Time Storage and Display

•

Oracle Utilities Application Framework

•

Typical Daylight Saving Time Scenarios

Types of Devices

In Oracle Utilities Service and Measurement Data Foundation initial measurement data processing, the application understands a device that is either:

a.

Aware of the fact that Local time in the device's time zone has been shifted from "Standard", or

b.

Unaware of any such shifting.

Devices in the "unaware" category ("b") will always send Oracle Utilities Service and Measurement Data Foundation initial measurement data with measurements in Standard time. Devices in the "aware" category ("a") will always send the application initial measurement data in Local time.

Whether a device falls into category "a" (Aware) or "b" (Unaware) is configured via the Incoming Data Shift flag on the device type (which can be overridden on the device). The values of the flag are:

•

"Always in Local Time" (used with "aware" devices, or category "a")

•

"Always in Standard Time" (used with "unaware" devices, or category "b")

This flag is used by pre-processing algorithms (Perform Date/Time Adjustments and Undercount/Overcount Check) in the IMD Seeder business object to convert any date/times on the initial measurement into standard time. Note that this conversion is only done if the device falls into category "a."

Date/Time Storage and Display

Within the database, measurements are stored with two (2) date/times: Standard and Local. The Service and Measurement Data Foundation uses the date/time in Standard as part of the prime key of the measurement table. The presence of the Local date/time field facilitates querying measurement data using local time.

When displaying dates and times for initial measurement data:

•

Display of the data on the Oracle Utilities Meter Data Management 360 View is in Local time.

•

The IMD Lens zone (in the Oracle Utilities Meter Data Management version of the Initial Measurement portal) also displays data in Local time.

•

The Raw Data, Pre-VEE and Post-VEE XML Data zone on the Initial Measurement portal does not shift the data into Local time, so if that the pre-processing algorithm has shifted the data into standard time, the date/times displayed will be in Standard time. Please note that the only two date/times visible in that zone will typically be the Start date/time and End date/time of the intial measurement; the Service and Measurement Data Foundation strips off the date/times from the individual intervals of the initial measurement at pre-processing time.

•

The Measurement zone shows both the local and standard date/times as-is.

Oracle Utilities Application Framework

When during initial measurement data processing, it is determined that time shifting is required, the meter data fanagement looks at the time zone metadata in the application. Oracle Utilities Application Framework utilizes the configuration of an Olson DB time zone code on the time zone metadata. This Olson DB contains the shift date/times for every time zone across the globe.

In North America for example, the available Olson DB time zone codes are much more specific than "Eastern/Central/Mountain/Pacific", and include details for areas places such as Arizona and Indiana where there may or may not be shifting for daylight saving time.

Oracle Utilities Application Framework provides business services that wrap the application services that perform time shifting. These services use the time zone metadata to retrieve shift date/times using the Olson DB.

Typical Daylight Saving Time Scenarios

The following table illustrates typical daylight saving time scenarios.

Time Springs Forward

Other Days

Time Falls Back

DST Shifted Meter in Local Time

Shift & Store time as standard in IMD

DST Shifted Meter in Local Time

Shift & Store time as standard in IMD

DST Shifted Meter in Local Time

Shift & Store time as standard in IMD

3/14/2011

3/14/2011

7/18/2011

7/18/2011

11/7/2011

11/7/2011

1:00

1:00

1:00

0:00

1:00

0:00

3:00

2:00

2:00

1:00

2:00

1:00

4:00

3:00

3:00

2:00

2:00

2:00

5:00

4:00

4:00

3:00

3:00

3:00

6:00

5:00

5:00

4:00

4:00

4:00

7:00

6:00

6:00

5:00

5:00

5:00

8:00

7:00

7:00

6:00

6:00

6:00

9:00

8:00

8:00

7:00

7:00

7:00

10:00

9:00

9:00

8:00

8:00

8:00

11:00

10:00

10:00

9:00

9:00

9:00

12:00

11:00

11:00

10:00

10:00

10:00

13:00

12:00

12:00

11:00

11:00

11:00

14:00

13:00

13:00

12:00

12:00

12:00

15:00

14:00

14:00

13:00

13:00

13:00

16:00

15:00

15:00

14:00

14:00

14:00

17:00

16:00

16:00

15:00

15:00

15:00

18:00

17:00

17:00

16:00

16:00

16:00

19:00

18:00

18:00

17:00

17:00

17:00

20:00

19:00

19:00

18:00

18:00

18:00

21:00

20:00

20:00

19:00

19:00

19:00

22:00

21:00

21:00

20:00

20:00

20:00

23:00

22:00

22:00

21:00

21:00

21:00

0:00

23:00

23:00

22:00

22:00

22:00

0:00

23:00

23:00

23:00

0:00

0:00

23 hours

23 hours

24 hours

24 hours

25 hours

25 hours

Bold -faced entries indicate times that are impacted by daylight saving time conversion.

Daylight Saving Time Support

This section describes how the Oracle Utilities Service and Measurement Data Foundation and its related products support Daylight Saving Time (DST) for measurement data, including:

•

Types of Devices

•

Date/Time Storage and Display

•

Oracle Utilities Application Framework

•

Typical Daylight Saving Time Scenarios

Types of Devices

In Oracle Utilities Service and Measurement Data Foundation initial measurement data processing, the application understands a device that is either:

a.

Aware of the fact that Local time in the device's time zone has been shifted from "Standard", or

b.

Unaware of any such shifting.

Devices in the "unaware" category ("b") will always send Oracle Utilities Service and Measurement Data Foundation initial measurement data with measurements in Standard time. Devices in the "aware" category ("a") will always send the application initial measurement data in Local time.

Whether a device falls into category "a" (Aware) or "b" (Unaware) is configured via the Incoming Data Shift flag on the device type (which can be overridden on the device). The values of the flag are:

•

"Always in Local Time" (used with "aware" devices, or category "a")

•

"Always in Standard Time" (used with "unaware" devices, or category "b")

This flag is used by pre-processing algorithms (Perform Date/Time Adjustments and Undercount/Overcount Check) in the IMD Seeder business object to convert any date/times on the initial measurement into standard time. Note that this conversion is only done if the device falls into category "a."

Date/Time Storage and Display

Within the database, measurements are stored with two (2) date/times: Standard and Local. The Service and Measurement Data Foundation uses the date/time in Standard as part of the prime key of the measurement table. The presence of the Local date/time field facilitates querying measurement data using local time.

When displaying dates and times for initial measurement data:

•

Display of the data on the Oracle Utilities Meter Data Management 360 View is in Local time.

•

The IMD Lens zone (in the Oracle Utilities Meter Data Management version of the Initial Measurement portal) also displays data in Local time.

•

The Raw Data, Pre-VEE and Post-VEE XML Data zone on the Initial Measurement portal does not shift the data into Local time, so if that the pre-processing algorithm has shifted the data into standard time, the date/times displayed will be in Standard time. Please note that the only two date/times visible in that zone will typically be the Start date/time and End date/time of the intial measurement; the Service and Measurement Data Foundation strips off the date/times from the individual intervals of the initial measurement at pre-processing time.

•

The Measurement zone shows both the local and standard date/times as-is.

Oracle Utilities Application Framework

When during initial measurement data processing, it is determined that time shifting is required, the meter data fanagement looks at the time zone metadata in the application. Oracle Utilities Application Framework utilizes the configuration of an Olson DB time zone code on the time zone metadata. This Olson DB contains the shift date/times for every time zone across the globe.

In North America for example, the available Olson DB time zone codes are much more specific than "Eastern/Central/Mountain/Pacific", and include details for areas places such as Arizona and Indiana where there may or may not be shifting for daylight saving time.

Oracle Utilities Application Framework provides business services that wrap the application services that perform time shifting. These services use the time zone metadata to retrieve shift date/times using the Olson DB.

Typical Daylight Saving Time Scenarios

The following table illustrates typical daylight saving time scenarios.

Time Springs Forward

Other Days

Time Falls Back

DST Shifted Meter in Local Time

Shift & Store time as standard in IMD

DST Shifted Meter in Local Time

Shift & Store time as standard in IMD

DST Shifted Meter in Local Time

Shift & Store time as standard in IMD

3/14/2011

3/14/2011

7/18/2011

7/18/2011

11/7/2011

11/7/2011

1:00

1:00

1:00

0:00

1:00

0:00

3:00

2:00

2:00

1:00

2:00

1:00

4:00

3:00

3:00

2:00

2:00

2:00

5:00

4:00

4:00

3:00

3:00

3:00

6:00

5:00

5:00

4:00

4:00

4:00

7:00

6:00

6:00

5:00

5:00

5:00

8:00

7:00

7:00

6:00

6:00

6:00

9:00

8:00

8:00

7:00

7:00

7:00

10:00

9:00

9:00

8:00

8:00

8:00

11:00

10:00

10:00

9:00

9:00

9:00

12:00

11:00

11:00

10:00

10:00

10:00

13:00

12:00

12:00

11:00

11:00

11:00

14:00

13:00

13:00

12:00

12:00

12:00

15:00

14:00

14:00

13:00

13:00

13:00

16:00

15:00

15:00

14:00

14:00

14:00

17:00

16:00

16:00

15:00

15:00

15:00

18:00

17:00

17:00

16:00

16:00

16:00

19:00

18:00

18:00

17:00

17:00

17:00

20:00

19:00

19:00

18:00

18:00

18:00

21:00

20:00

20:00

19:00

19:00

19:00

22:00

21:00

21:00

20:00

20:00

20:00

23:00

22:00

22:00

21:00

21:00

21:00

0:00

23:00

23:00

22:00

22:00

22:00

0:00

23:00

23:00

23:00

0:00

0:00

23 hours

23 hours

24 hours

24 hours

25 hours

25 hours

Bold -faced entries indicate times that are impacted by daylight saving time conversion.

Daylight Saving Time Support

This section describes how the Oracle Utilities Service and Measurement Data Foundation and its related products support Daylight Saving Time (DST) for measurement data, including:

•

Types of Devices

•

Date/Time Storage and Display

•

Oracle Utilities Application Framework

•

Typical Daylight Saving Time Scenarios

Types of Devices

In Oracle Utilities Service and Measurement Data Foundation initial measurement data processing, the application understands a device that is either:

a.

Aware of the fact that Local time in the device's time zone has been shifted from "Standard", or

b.

Unaware of any such shifting.

Devices in the "unaware" category ("b") will always send Oracle Utilities Service and Measurement Data Foundation initial measurement data with measurements in Standard time. Devices in the "aware" category ("a") will always send the application initial measurement data in Local time.

Whether a device falls into category "a" (Aware) or "b" (Unaware) is configured via the Incoming Data Shift flag on the device type (which can be overridden on the device). The values of the flag are:

•

"Always in Local Time" (used with "aware" devices, or category "a")

•

"Always in Standard Time" (used with "unaware" devices, or category "b")

This flag is used by pre-processing algorithms (Perform Date/Time Adjustments and Undercount/Overcount Check) in the IMD Seeder business object to convert any date/times on the initial measurement into standard time. Note that this conversion is only done if the device falls into category "a."

Date/Time Storage and Display

Within the database, measurements are stored with two (2) date/times: Standard and Local. The Service and Measurement Data Foundation uses the date/time in Standard as part of the prime key of the measurement table. The presence of the Local date/time field facilitates querying measurement data using local time.

When displaying dates and times for initial measurement data:

•

Display of the data on the Oracle Utilities Meter Data Management 360 View is in Local time.

•

The IMD Lens zone (in the Oracle Utilities Meter Data Management version of the Initial Measurement portal) also displays data in Local time.

•

The Raw Data, Pre-VEE and Post-VEE XML Data zone on the Initial Measurement portal does not shift the data into Local time, so if that the pre-processing algorithm has shifted the data into standard time, the date/times displayed will be in Standard time. Please note that the only two date/times visible in that zone will typically be the Start date/time and End date/time of the intial measurement; the Service and Measurement Data Foundation strips off the date/times from the individual intervals of the initial measurement at pre-processing time.

•

The Measurement zone shows both the local and standard date/times as-is.

Oracle Utilities Application Framework

When during initial measurement data processing, it is determined that time shifting is required, the meter data fanagement looks at the time zone metadata in the application. Oracle Utilities Application Framework utilizes the configuration of an Olson DB time zone code on the time zone metadata. This Olson DB contains the shift date/times for every time zone across the globe.

In North America for example, the available Olson DB time zone codes are much more specific than "Eastern/Central/Mountain/Pacific", and include details for areas places such as Arizona and Indiana where there may or may not be shifting for daylight saving time.

Oracle Utilities Application Framework provides business services that wrap the application services that perform time shifting. These services use the time zone metadata to retrieve shift date/times using the Olson DB.

Typical Daylight Saving Time Scenarios

The following table illustrates typical daylight saving time scenarios.

Time Springs Forward

Other Days

Time Falls Back

DST Shifted Meter in Local Time

Shift & Store time as standard in IMD

DST Shifted Meter in Local Time

Shift & Store time as standard in IMD

DST Shifted Meter in Local Time

Shift & Store time as standard in IMD

3/14/2011

3/14/2011

7/18/2011

7/18/2011

11/7/2011

11/7/2011

1:00

1:00

1:00

0:00

1:00

0:00

3:00

2:00

2:00

1:00

2:00

1:00

4:00

3:00

3:00

2:00

2:00

2:00

5:00

4:00

4:00

3:00

3:00

3:00

6:00

5:00

5:00

4:00

4:00

4:00

7:00

6:00

6:00

5:00

5:00

5:00

8:00

7:00

7:00

6:00

6:00

6:00

9:00

8:00

8:00

7:00

7:00

7:00

10:00

9:00

9:00

8:00

8:00

8:00

11:00

10:00

10:00

9:00

9:00

9:00

12:00

11:00

11:00

10:00

10:00

10:00

13:00

12:00

12:00

11:00

11:00

11:00

14:00

13:00

13:00

12:00

12:00

12:00

15:00

14:00

14:00

13:00

13:00

13:00

16:00

15:00

15:00

14:00

14:00

14:00

17:00

16:00

16:00

15:00

15:00

15:00

18:00

17:00

17:00

16:00

16:00

16:00

19:00

18:00

18:00

17:00

17:00

17:00

20:00

19:00

19:00

18:00

18:00

18:00

21:00

20:00

20:00

19:00

19:00

19:00

22:00

21:00

21:00

20:00

20:00

20:00

23:00

22:00

22:00

21:00

21:00

21:00

0:00

23:00

23:00

22:00

22:00

22:00

0:00

23:00

23:00

23:00

0:00

0:00

23 hours

23 hours

24 hours

24 hours

25 hours

25 hours

Bold -faced entries indicate times that are impacted by daylight saving time conversion.

Daylight Saving Time Support

This section describes how the Oracle Utilities Service and Measurement Data Foundation and its related products support Daylight Saving Time (DST) for measurement data, including:

•

Types of Devices

•

Date/Time Storage and Display

•

Oracle Utilities Application Framework

•

Typical Daylight Saving Time Scenarios

Types of Devices

In Oracle Utilities Service and Measurement Data Foundation initial measurement data processing, the application understands a device that is either:

a.

Aware of the fact that Local time in the device's time zone has been shifted from "Standard", or

b.

Unaware of any such shifting.

Devices in the "unaware" category ("b") will always send Oracle Utilities Service and Measurement Data Foundation initial measurement data with measurements in Standard time. Devices in the "aware" category ("a") will always send the application initial measurement data in Local time.

Whether a device falls into category "a" (Aware) or "b" (Unaware) is configured via the Incoming Data Shift flag on the device type (which can be overridden on the device). The values of the flag are:

•

"Always in Local Time" (used with "aware" devices, or category "a")

•

"Always in Standard Time" (used with "unaware" devices, or category "b")

This flag is used by pre-processing algorithms (Perform Date/Time Adjustments and Undercount/Overcount Check) in the IMD Seeder business object to convert any date/times on the initial measurement into standard time. Note that this conversion is only done if the device falls into category "a."

Date/Time Storage and Display

Within the database, measurements are stored with two (2) date/times: Standard and Local. The Service and Measurement Data Foundation uses the date/time in Standard as part of the prime key of the measurement table. The presence of the Local date/time field facilitates querying measurement data using local time.

When displaying dates and times for initial measurement data:

•

Display of the data on the Oracle Utilities Meter Data Management 360 View is in Local time.

•

The IMD Lens zone (in the Oracle Utilities Meter Data Management version of the Initial Measurement portal) also displays data in Local time.

•

The Raw Data, Pre-VEE and Post-VEE XML Data zone on the Initial Measurement portal does not shift the data into Local time, so if that the pre-processing algorithm has shifted the data into standard time, the date/times displayed will be in Standard time. Please note that the only two date/times visible in that zone will typically be the Start date/time and End date/time of the intial measurement; the Service and Measurement Data Foundation strips off the date/times from the individual intervals of the initial measurement at pre-processing time.

•

The Measurement zone shows both the local and standard date/times as-is.

Oracle Utilities Application Framework

When during initial measurement data processing, it is determined that time shifting is required, the meter data fanagement looks at the time zone metadata in the application. Oracle Utilities Application Framework utilizes the configuration of an Olson DB time zone code on the time zone metadata. This Olson DB contains the shift date/times for every time zone across the globe.

In North America for example, the available Olson DB time zone codes are much more specific than "Eastern/Central/Mountain/Pacific", and include details for areas places such as Arizona and Indiana where there may or may not be shifting for daylight saving time.

Oracle Utilities Application Framework provides business services that wrap the application services that perform time shifting. These services use the time zone metadata to retrieve shift date/times using the Olson DB.

Typical Daylight Saving Time Scenarios

The following table illustrates typical daylight saving time scenarios.

Time Springs Forward

Other Days

Time Falls Back

DST Shifted Meter in Local Time

Shift & Store time as standard in IMD

DST Shifted Meter in Local Time

Shift & Store time as standard in IMD

DST Shifted Meter in Local Time

Shift & Store time as standard in IMD

3/14/2011

3/14/2011

7/18/2011

7/18/2011

11/7/2011

11/7/2011

1:00

1:00

1:00

0:00

1:00

0:00

3:00

2:00

2:00

1:00

2:00

1:00

4:00

3:00

3:00

2:00

2:00

2:00

5:00

4:00

4:00

3:00

3:00

3:00

6:00

5:00

5:00

4:00

4:00

4:00

7:00

6:00

6:00

5:00

5:00

5:00

8:00

7:00

7:00

6:00

6:00

6:00

9:00

8:00

8:00

7:00

7:00

7:00

10:00

9:00

9:00

8:00

8:00

8:00

11:00

10:00

10:00

9:00

9:00

9:00

12:00

11:00

11:00

10:00

10:00

10:00

13:00

12:00

12:00

11:00

11:00

11:00

14:00

13:00

13:00

12:00

12:00

12:00

15:00

14:00

14:00

13:00

13:00

13:00

16:00

15:00

15:00

14:00

14:00

14:00

17:00

16:00

16:00

15:00

15:00

15:00

18:00

17:00

17:00

16:00

16:00

16:00

19:00

18:00

18:00

17:00

17:00

17:00

20:00

19:00

19:00

18:00

18:00

18:00

21:00

20:00

20:00

19:00

19:00

19:00

22:00

21:00

21:00

20:00

20:00

20:00

23:00

22:00

22:00

21:00

21:00

21:00

0:00

23:00

23:00

22:00

22:00

22:00

0:00

23:00

23:00

23:00

0:00

0:00

23 hours

23 hours

24 hours

24 hours

25 hours

25 hours

Bold -faced entries indicate times that are impacted by daylight saving time conversion.

Daylight Saving Time Support

This section describes how the Oracle Utilities Service and Measurement Data Foundation and its related products support Daylight Saving Time (DST) for measurement data, including:

•

Types of Devices

•

Date/Time Storage and Display

•

Oracle Utilities Application Framework

•

Typical Daylight Saving Time Scenarios

Types of Devices

In Oracle Utilities Service and Measurement Data Foundation initial measurement data processing, the application understands a device that is either:

a.

Aware of the fact that Local time in the device's time zone has been shifted from "Standard", or

b.

Unaware of any such shifting.

Devices in the "unaware" category ("b") will always send Oracle Utilities Service and Measurement Data Foundation initial measurement data with measurements in Standard time. Devices in the "aware" category ("a") will always send the application initial measurement data in Local time.

Whether a device falls into category "a" (Aware) or "b" (Unaware) is configured via the Incoming Data Shift flag on the device type (which can be overridden on the device). The values of the flag are:

•

"Always in Local Time" (used with "aware" devices, or category "a")

•

"Always in Standard Time" (used with "unaware" devices, or category "b")

This flag is used by pre-processing algorithms (Perform Date/Time Adjustments and Undercount/Overcount Check) in the IMD Seeder business object to convert any date/times on the initial measurement into standard time. Note that this conversion is only done if the device falls into category "a."

Date/Time Storage and Display

Within the database, measurements are stored with two (2) date/times: Standard and Local. The Service and Measurement Data Foundation uses the date/time in Standard as part of the prime key of the measurement table. The presence of the Local date/time field facilitates querying measurement data using local time.

When displaying dates and times for initial measurement data:

•

Display of the data on the Oracle Utilities Meter Data Management 360 View is in Local time.

•

The IMD Lens zone (in the Oracle Utilities Meter Data Management version of the Initial Measurement portal) also displays data in Local time.

•

The Raw Data, Pre-VEE and Post-VEE XML Data zone on the Initial Measurement portal does not shift the data into Local time, so if that the pre-processing algorithm has shifted the data into standard time, the date/times displayed will be in Standard time. Please note that the only two date/times visible in that zone will typically be the Start date/time and End date/time of the intial measurement; the Service and Measurement Data Foundation strips off the date/times from the individual intervals of the initial measurement at pre-processing time.

•

The Measurement zone shows both the local and standard date/times as-is.

Oracle Utilities Application Framework

When during initial measurement data processing, it is determined that time shifting is required, the meter data fanagement looks at the time zone metadata in the application. Oracle Utilities Application Framework utilizes the configuration of an Olson DB time zone code on the time zone metadata. This Olson DB contains the shift date/times for every time zone across the globe.

In North America for example, the available Olson DB time zone codes are much more specific than "Eastern/Central/Mountain/Pacific", and include details for areas places such as Arizona and Indiana where there may or may not be shifting for daylight saving time.

Oracle Utilities Application Framework provides business services that wrap the application services that perform time shifting. These services use the time zone metadata to retrieve shift date/times using the Olson DB.

Typical Daylight Saving Time Scenarios

The following table illustrates typical daylight saving time scenarios.

Time Springs Forward

Other Days

Time Falls Back

DST Shifted Meter in Local Time

Shift & Store time as standard in IMD

DST Shifted Meter in Local Time

Shift & Store time as standard in IMD

DST Shifted Meter in Local Time

Shift & Store time as standard in IMD

3/14/2011

3/14/2011

7/18/2011

7/18/2011

11/7/2011

11/7/2011

1:00

1:00

1:00

0:00

1:00

0:00

3:00

2:00

2:00

1:00

2:00

1:00

4:00

3:00

3:00

2:00

2:00

2:00

5:00

4:00

4:00

3:00

3:00

3:00

6:00

5:00

5:00

4:00

4:00

4:00

7:00

6:00

6:00

5:00

5:00

5:00

8:00

7:00

7:00

6:00

6:00

6:00

9:00

8:00

8:00

7:00

7:00

7:00

10:00

9:00

9:00

8:00

8:00

8:00

11:00

10:00

10:00

9:00

9:00

9:00

12:00

11:00

11:00

10:00

10:00

10:00

13:00

12:00

12:00

11:00

11:00

11:00

14:00

13:00

13:00

12:00

12:00

12:00

15:00

14:00

14:00

13:00

13:00

13:00

16:00

15:00

15:00

14:00

14:00

14:00

17:00

16:00

16:00

15:00

15:00

15:00

18:00

17:00

17:00

16:00

16:00

16:00

19:00

18:00

18:00

17:00

17:00

17:00

20:00

19:00

19:00

18:00

18:00

18:00

21:00

20:00

20:00

19:00

19:00

19:00

22:00

21:00

21:00

20:00

20:00

20:00

23:00

22:00

22:00

21:00

21:00

21:00

0:00

23:00

23:00

22:00

22:00

22:00

0:00

23:00

23:00

23:00

0:00

0:00

23 hours

23 hours

24 hours

24 hours

25 hours

25 hours

Bold -faced entries indicate times that are impacted by daylight saving time conversion.

Initial Measurement Data In Detail

This section provides details concerning the initial measurement data objects supplied as part of the base package. This information illustrates how the base package objects were designed, and can serve as the basis for any custom initial measurement data objects you create as part of your implementation. This section includes:

•

A description of the D1-IMD maintenance object

•

Lists of the base package initial measurement data business objects, including "lite" business objects

•

Details concerning initial measurement data specific configuration options

•

A sample initial measurement data business object (D1-InitialLoadIMDInterval)

Maintenance Object - D1-IMD

Initial measurement business objects use the D1-IMD maintenance object. The table below outlines some of the details of this maintenance object.

Option/Field

Description

Maintenance Object

D1-IMD

Description

Initial Measurement

Service Name

D1-INITMSRMTDATA (Initial Measurement Maintenance)

Tables

•

D1_INIT_MSRMT_DATA (Initial Measurement) - Primary

•

D1_INIT_MSRMT_DATA_CHAR (Initial Measurement Characteristics) - Child

•

D1_INIT_MSRMT_DATA_LOG (Initial Measurement Log) - Child

•

D1_INIT_MSRMT_DATA_LOG_PARM (Initial Measurement Log Parameters) - Child

Use the Maintenance Object portal and the Application Viewer to view more details about this maintenance object.

Base Package Business Objects

The base package includes the following initial measurement data business objects:

Business Object Name

Description

D1-EstimationIMDInterval

Estimation IMD (Interval)

Instances of this business object represent individual estimated inteval initial measurements in the system.

D1-EstimationIMDScalar

Estimation IMD (Scalar)

Instances of this business object represent individual estimated scalar initial measurements in the system.

D1-InitialLoadIMDInterval

Initial Load IMD (Interval)

Instances of this business object represent individual inteval initial measurements in the system.

D1-InitialLoadIMDScalar

Initial Load IMD (Scalar)

Instances of this business object represent individual scalar initial measurements in the system.

D1-ManualIMDInterval

Manual IMD (Interval)

Instances of this business object represent individual manually-created inteval initial measurements in the system.

D1-ManualIMDScalar

Manual IMD (Scalar)

Instances of this business object represent individual manually-created scalar initial measurements in the system.

D1-SyncIMDScalar

Sync Request IMD (Scalar)

Instances of this business object represent individual scalar initial measurements in the system created via synchronization requests from an external system.

Note: Initial measurements created using this business object are not subject to VEE processing. Because the data originate from an external application where it had already been loaded, this business object assumes the reading is valid.

The base package includes the following "lite" initial measurement data business objects:

Business Object Name

Description

D1-AuditList - IMD

Audit List Section Only (Lite)

D1-GenericIMDMain - IMD

IMD - Main Section Only LITE

D1-IMDLite

IMD LITE

D1-IMDParentLITE

IMD Parent LITE

D1-IMDPeriod

IMD Lite for High Quality Check

D1-IMDPostVEE

IMD Main and Post VEE LITE

D1-IMDPostVEERaw

IMD Main and Post VEE Raw LITE

D1-IMDPreAndPostVEE

IMD Pre and Post VEE - Lite

D1-IMDPreVEE

IMD Main and Pre VEE LITE

D1-IMDRawData

Intial Measurement Data Raw Lite

D1-IMDRetry

IMD Retry BO LITE

D1-IMDSeederLite

IMD Seeder Lite

D1-IMDTraceAndPostVEE

IMD Trace and Post VEE - Lite

D1-IMDTraceZone

IMD - Trace List Section Only LITE

D1-InitialLoadIMDIntervalRaw

Initial Load IMD (Interval) - Raw LITE

D1-IntialLoadIMDMain

Initial Load IMD - Main Section Only LITE

D1-PostVEE

Post VEE Only LITE

D1-PreVEE

Pre VEE Only LITE

The base package includes the following additional initial measurement data business objects:

Business Object Name

Description

D1-IMDSeeder

IMD Seeder (used to instantiate initial measurement business objects, based on the head-end system sending the measurement)

D1-SyncIMDScalar

Sync Request IMD (Scalar)

Configuration Options

This section outlines specific configuration options, such as business object options, system events, and other options used by initial measurement data business objects.

Business Object Options

Initial measurement business objects can make use of the following business object options:

•

Apply Multiplier to Pre-VEE (Y/N) : This option indicates whether or not multiplier and other consumption factors are to be applied to Pre-VEE measurement data.

•

Channel Status Code Mapping : This option defines an extendable lookup used for mapping vendor-specific channel status codes to standard codes.

•

Initial Measurement Data Type : This option defines the data type for initial measurement data created from this business object. Valid values are based on the D1_IMD_TYPE_FLG lookup, and include the following:

Field Value

Description

D1GA

IMD Seeder

D1IL

Initial Load

D1MO

Manual

D1ES

Estimation

•

Interval Status Mapping to Condition with Priority : This option defines the Interval Status Code extendable lookup that can be used to map status codes for initial measurement data created from this business object.

•

Override Automated Retry (Y/N) : This option indicate whether or not the execution of the IMD Automated Retry process should be forced regardless of the value of the IMD Automated Retry flag in the BO schema.

Configuration Options

This section outlines specific configuration options, such as business object options, system events, and other options used by initial measurement data business objects.

Business Object Options

Initial measurement business objects can make use of the following business object options:

•

Apply Multiplier to Pre-VEE (Y/N) : This option indicates whether or not multiplier and other consumption factors are to be applied to Pre-VEE measurement data.

•

Channel Status Code Mapping : This option defines an extendable lookup used for mapping vendor-specific channel status codes to standard codes.

•

Initial Measurement Data Type : This option defines the data type for initial measurement data created from this business object. Valid values are based on the D1_IMD_TYPE_FLG lookup, and include the following:

Field Value

Description

D1GA

IMD Seeder

D1IL

Initial Load

D1MO

Manual

D1ES

Estimation

•

Interval Status Mapping to Condition with Priority : This option defines the Interval Status Code extendable lookup that can be used to map status codes for initial measurement data created from this business object.

•

Override Automated Retry (Y/N) : This option indicate whether or not the execution of the IMD Automated Retry process should be forced regardless of the value of the IMD Automated Retry flag in the BO schema.

Example Initial Measurement - D1-InitialLoadIMDInterval

The table below lists the details of the D1-InitialLoadIMDInterval initial measurement data business object.

Option/Field

Description

Business Object

D1-InitialLoadIMDInterval

Description

Initial Load IMD (Interval)

Maintenance Object

D1-IMD (Initial Measurement Data)

Application Service

D1-INITLOADIMDBOAS (Initial Load IMD Interval BO)

Instance Control

Allow New Instances

Options

•

Initial Measurement Data Type: D1IL (Initial Load)

•

Override Automated Retry (Y/N): Y

•

Display UI Map: D1-IMDDisplay (Initial Measurement Data - Display)

•

Portal Navigation Option: d1imdsaTabMenu (Initial Measurement)

•

Display Map Service Script: D1-IMDDisp (Initial Measurement Data Display)

•

Maintenance UI Map: D1-IMDMaint (Initial Load IMD (Interval) - Maintenance)

Algorithms

•

Post-Processing: D1-AUD-QTYUE (Audit IMD Quantity Changes made to Quantity and Set User-Edited Flag)

•

Validation: D1-IMD-VAL (Validates Status Condition for Delete)

•

Validation: D1-IMD-COMM (Validate Initial Measurement Data Common Input)

•

Validation: D1-INT-SPEC (Validate Interval Initial Measurement Data Input)

Lifecycle

•

Pending (Initial)

•

Additional Mapping (Interim)

•

Mapping Error (Interim)

•

VEE Ready (Interim)

•

Error (Interim)

•

Removed from Processing (Final)

•

VEE Complete (Interim)

•

Exception (Interim)

•

Discarded (Final)

•

Force Complete (Interim)

•

Finalized (Final)

Use the Business Object portal to view additional details concerning this business object.

Measurements In Detail

This section provides details concerning the measurement objects supplied as part of the base package. This information illustrates how the base package objects were designed, and can serve as the basis for any custom measurement objects you create as part of your implementation. This section includes:

•

A description of the D1-MSRMT maintenance object

•

Lists of the base package measurement business objects, including "lite" business objects

•

Details concerning measurement-specific configuration options

•

A sample measurement business object (D1-Measurement)

Maintenance Object - D1-MSRMT

Measurement business objects use the D1-MSRMT maintenance object. The table below outlines some of the details of this maintenance object.

Option/Field

Description

Maintenance Object

D1-MSRMT

Description

Measurement

Service Name

D1-MEASUREMENT (Measurement Maintenance)

Tables

•

D1-MSRMT (Measurement) - Primary

•

D1-MSRMT_CHAR (Measurement Characteristics - Child

Use the Maintenance Object portal and the Application Viewer to view more details about this maintenance object.

Base Package Device Business Objects

The base package includes the following measurement business objects:

Business Object Name

Description

D1-Measurement

Measurement

Instances of this business object represent individual final measurements stored in the system.

The base package includes the following "lite" device business objects:

Business Object Name

Description

D1-MeasurementParentLITE

Measurement Parent LITE

D1-MSRMTLite

Measurement LITE

Configuration Options

This section outlines specific configuration options, such as business object options, system events, and other options used by measurement business objects.

Business Object Options

Measurement business objects can make use of the following business object options:

•

Measurement Log Business Object : This option defines the business object that will be used to log changes that have occurred to the measurement.

Configuration Options

This section outlines specific configuration options, such as business object options, system events, and other options used by measurement business objects.

Business Object Options

Measurement business objects can make use of the following business object options:

•

Measurement Log Business Object : This option defines the business object that will be used to log changes that have occurred to the measurement.

Example Device - D1-Measurement

The table below lists the details of the D1-Measurement device business object.

Option/Field

Description

Business Object

D1-Measurement

Description

Measurement

Maintenance Object

D1-MSRMT (Measurement)

Application Service

D1-MEASUREMENT (Measurement MO)

Instance Control

Allow New Instances

Options

•

Measurement Log Business Object: D1-MeasurementLog (Measurement Log)

•

Display UI Map: D1-MeasurementDisplay (Measurement - Display)

•

Portal Navigation Option: d1meassaTabMenu (Measurement)

•

Display Map Service Script: D2-MsrmtDisp (Measurement Data Display)

Algorithms

•

Audit: D1-AMSRMTLOG (Formats the standard description of a Measurement)

•

Information: D1-MSRMTINFO (Measurement Information)

Use the Business Object portal to view additional details concerning this business object.

Configuring Initial Measurements and Measurements

This section provides high-level overviews of the steps involved in configuring custom objects to define initial measurements and (final) measurements. See Configuration Process Overview in Chapter One for a high-level overview of the overall configuration process.

Note : The procedures below focus on specific configuration tasks and options related to each of the objects described in this chapter, and do not address all the steps involved in creating business objects, UI maps, algorithms, etc. For more information about these subjects, refer to the Oracle Utilities Application Framework documentation.

Configuring Custom Initial Measurements

Configuring custom initial measurement objects involves the following steps:

1.

Design the initial measurement business objects you will need to create for your implementation, including the data and processing required for each.

2.

Create the custom initial measurement-related configuration objects required for your business objects, including:

Business Object Options : Create business objects for the following business object options:

•

IMD Status Extendable Lookup

3.

Create your initial measurement business objects, referencing the configuration objects created above as appropriate.

Configuring Reader Remark Types

Configuring reader remark types involves the following:

1.

Determine the specific types of reader remarks that meter readers will be able to specify when reading meters.

Note that reader remark types do not allow readers to enter free text. They must select from a pre-defined list of remark types. Examples might include "BROKEN_SEAL", "DAMAGED_METER", "EVIDENCE_ OF_TAMPERING", "DOG_ON_PREMISES", etc.

2.

Define a reader remark type (device event type) for each type of reader remark identified in step 1 above. Define the following for each:

•

Reporting Category

•

Eligible for Processing

•

To Do Types

•

To Do Roles

•

Service Issue Monitor Type

Refer to the Oracle Utilities Service and Measurement Data Foundation User’s Guide for more information about defining reader remark types.

Configuring Custom Measurements

Configuring custom measurement objects involves the following steps:

1.

Design the measurement business objects you will need to create for your implementation, including the data and processing required for each.

2.

Create the custom measurement-related configuration objects required for your business objects, including:

Business Object Options : Create business objects for the following business object options:

•

Measurement Log Business Object

3.

Create your initial measurement business objects, referencing the configuration objects created above as appropriate.

Device Communication and Device Events

This chapter provides descriptions of entities related to device communications, including activities, communications, and completion events. This chapter also describes entities related to device events. This chapter includes:

•

Understanding Activities

•

Understanding Commands and Device Communication

•

Understanding Bulk Commands

•

Understanding Device Events

•

Activities In Detail

•

Inbound Communications In Detail

•

Outbound Communications In Detail

•

Completion Events In Detail

•

Device Events In Detail

•

Configuring Activities and Device Events

•

Configuring Device Communication and Device Event Objects

Understanding Activities

This section provides an overview of activities and how they are used in the Service and Measurement Data Foundation and related products, including Oracle Utilities Meter Data Management and Oracle Utilities Smart Grid Gateway.

About Activities

Activities are records of a communication or event related to a device, measuring component, service point or other entity in the system. Examples of activities include meter read downloads (for manually read meters) or "last gasp" messages sent by devices when they detects they are about to power down.

Oracle Utilities Smart Grid Gateway Activities

Activities are used extensively in Oracle Utilities Smart Grid Gateway to record meter commands such as device commissioning/decommissioning, remote connect/disconnect, device status check, or on-demand reading commands.

Activities are also used in Oracle Utilities Smart Grid Gateway to track statistics related to uploading initial measurements and device events sent from head-end systems.

About Activities

Activities are records of a communication or event related to a device, measuring component, service point or other entity in the system. Examples of activities include meter read downloads (for manually read meters) or "last gasp" messages sent by devices when they detects they are about to power down.

Oracle Utilities Smart Grid Gateway Activities

Activities are used extensively in Oracle Utilities Smart Grid Gateway to record meter commands such as device commissioning/decommissioning, remote connect/disconnect, device status check, or on-demand reading commands.

Activities are also used in Oracle Utilities Smart Grid Gateway to track statistics related to uploading initial measurements and device events sent from head-end systems.

Understanding Commands and Device Communication

This section provides an overview of entities related to device communications, including commands activities, communications, and completion events and how they are used in the Service and Measurement Data Foundation and related products, including Oracle Utilities Smart Grid Gateway.

Activities

Activities are used in Oracle Utilities Smart Grid Gateway to record meter commands such as device commissioning/decommissioning, remote connect/disconnect, device status check, or on-demand reading commands. Activities are also used in Oracle Utilities Smart Grid Gateway to track statistics related to uploading initial measurements and device events sent from head-end systems.

Commands

Commands issued to devices, such as remote connect, remote disconnect, and others are defined as activities. These represent commands sent via Oracle Utilities Smart Grid Gateway to devices to invoke a specific type of action.

The table below outlines the commands supported by Oracle Utilities Smart Grid Gateway.

Command

Description

Commission Device

A command issued to establish communication between a device and the head-end system. The goal is to ensure connectivity has been established with the device, that any information needed to communicate with the device has been defined in both Oracle Utilities Smart Grid Gateway and the head-end system, and that the device will begin capturing usage and events.

Decommission Device

A command issued to inform the head-end system when a device needs to be removed from a service point, so that no further reads or events will arrive from the device. Decommissioning is invoked when a device must be removed or deactivated. The goal is to stop any communication between the device and the head-end system.

Device Status Check

A command used to test whether the device is communicating with the network, determine the connection status of the device, and when possible, and check if there are any known malfunctions.

On-Demand Read

A request for the most up-to-date reading from a particular device. These commands are not guaranteed to return immediately. In some cases, completing the command might require a person to manually read the device. The purposes are to check the operational status of the device and/or obtain a more recent reading than is currently available.

Remote Connect

A command issued when a device needs to be connected at a service point.

Remote Disconnect

A command issued when a device needs to be disconnected or shut off at a service point.

Attributes used to define commands include the following:

•

Parent Activity: the parent activity (if any) for the command.

•

Command Effective Date/Time : the date and time on which the command takes effect. Commands issued prior to this date and time remain in the "Waiting for Effective Date" status until this time, at which time the command is executed.

•

Command Expiration Date/Time : the date time when the command expires. The command cannot be executed after this date and time.

•

Priority : the priority for the command.

•

Requester : the application sending the command.

•

Requester User : the user who initiated the command.

•

Requester Transaction ID : an ID for the command, defined by the requester.

•

Utility Device ID : ID of the device used by the utility. Used to derive the device ID if the device ID is not provided.

When a command is initiated, it in turn creates an outbound communication which sends the command request to the head-end system.

Upload Statistics

Upload statistics are statistics related to the uploading of initial measurement data and device events sent from a head-end system, and are defined as activities in the system. This section describes upload statistics and how they are captured and maintained in Oracle Utilities Smart Grid Gateway, including:

•

Upload Statistics Activities

•

Upload Statistics - XAI Inbound Services

•

Head-End System Processing Statistics

Upload Statistics Activities

There are three types of upload statistics activities:

•

Payload Statistics : Contains statistics related to a specific payload (file) containing one or more initial measurements or device events. Payload Statistics activities contain:

•

Basic information about the payload (head-end system, file name, and status)

•

Middleware statistics including specifics about the file, the total number of initial measurements or device events processed, the number of initial measurement or device events errors, and total processing time

•

Initial measurement statistics including the number of initial measurements processed

•

Device event statistics including the number of device events processed

•

Payload Error Notification : Contains details concerning processing errors encountered in an individual payload (file) containing one or more initial measurements or device events. Payload Error Notification activities are related to Payload Statistics activities.

•

Payload Summary : Contains processing summary statistics for an individual payload (file) containing one or more initial measurements or device events. Payload Summary activities are related to Payload Statistics activities, and are used to update related payload statistics upon the completion of payload processing.

Upload statistics activities are created during processing of payload files as follows:

•

When processing begins for a payload, a Payload Statistics activity is created to record the process.

•

If an error occurs during processing, a Payload Error Notification activity is created.

•

When payload processing is complete, a Payload Summary activity is created, which in turn, updates the Payload Statistics activity with details concerning the processing of the payload, including the start and end time of the processing, the total processing time, the number of initial measurements or device events processed, and the number of initial measurement or device event errors (if any).

Upload Statistics - XAI Inbound Services

Upload statistics activities are created by the middleware components used by Smart Grid Gatewaty adapters via XAI inbound services. XAI inbound services define the details of how messages are received from an external system, including the activity business object to be invoked when the response message is received. Smart Grid Gateway adapters use a set of XAI inbound services to create upload statistics activities, outlined in the table below:

This type of Upload Statistics Activity...

Is created by this type of

XAI Inbound Service

D1-PayloadStatistics

D1-PayloadStatistics

D1-PayloadSummary

D1-PayloadSummary

D1-PayloadErrorNotif

D1-PayloadErrorNotif

Refer to the Oracle Utilities Application Framework documentation for more information about XAI Inbound Services.

Head-End System Processing Statistics

As Oracle Utilities Smart Grid Gateway processes payloads containing initial measurements or device events, statistics for each payload are captured in Payload Statistics activities. Over time, payload statistics for each head-end system are summarized to allow administrators to view summary statistics for the head-end system. These summarized statistics are referred to as head-end system processing statistics.

Head-end system processing statistics are stored as aggregated measurements for aggregator measuring components. A separate aggregator measuring component must be set up for each head-end system for which processing statistics will be aggregated.

Activities

Activities are used in Oracle Utilities Smart Grid Gateway to record meter commands such as device commissioning/decommissioning, remote connect/disconnect, device status check, or on-demand reading commands. Activities are also used in Oracle Utilities Smart Grid Gateway to track statistics related to uploading initial measurements and device events sent from head-end systems.

Commands

Commands issued to devices, such as remote connect, remote disconnect, and others are defined as activities. These represent commands sent via Oracle Utilities Smart Grid Gateway to devices to invoke a specific type of action.

The table below outlines the commands supported by Oracle Utilities Smart Grid Gateway.

Command

Description

Commission Device

A command issued to establish communication between a device and the head-end system. The goal is to ensure connectivity has been established with the device, that any information needed to communicate with the device has been defined in both Oracle Utilities Smart Grid Gateway and the head-end system, and that the device will begin capturing usage and events.

Decommission Device

A command issued to inform the head-end system when a device needs to be removed from a service point, so that no further reads or events will arrive from the device. Decommissioning is invoked when a device must be removed or deactivated. The goal is to stop any communication between the device and the head-end system.

Device Status Check

A command used to test whether the device is communicating with the network, determine the connection status of the device, and when possible, and check if there are any known malfunctions.

On-Demand Read

A request for the most up-to-date reading from a particular device. These commands are not guaranteed to return immediately. In some cases, completing the command might require a person to manually read the device. The purposes are to check the operational status of the device and/or obtain a more recent reading than is currently available.

Remote Connect

A command issued when a device needs to be connected at a service point.

Remote Disconnect

A command issued when a device needs to be disconnected or shut off at a service point.

Attributes used to define commands include the following:

•

Parent Activity: the parent activity (if any) for the command.

•

Command Effective Date/Time : the date and time on which the command takes effect. Commands issued prior to this date and time remain in the "Waiting for Effective Date" status until this time, at which time the command is executed.

•

Command Expiration Date/Time : the date time when the command expires. The command cannot be executed after this date and time.

•

Priority : the priority for the command.

•

Requester : the application sending the command.

•

Requester User : the user who initiated the command.

•

Requester Transaction ID : an ID for the command, defined by the requester.

•

Utility Device ID : ID of the device used by the utility. Used to derive the device ID if the device ID is not provided.

When a command is initiated, it in turn creates an outbound communication which sends the command request to the head-end system.

Upload Statistics

Upload statistics are statistics related to the uploading of initial measurement data and device events sent from a head-end system, and are defined as activities in the system. This section describes upload statistics and how they are captured and maintained in Oracle Utilities Smart Grid Gateway, including:

•

Upload Statistics Activities

•

Upload Statistics - XAI Inbound Services

•

Head-End System Processing Statistics

Upload Statistics Activities

There are three types of upload statistics activities:

•

Payload Statistics : Contains statistics related to a specific payload (file) containing one or more initial measurements or device events. Payload Statistics activities contain:

•

Basic information about the payload (head-end system, file name, and status)

•

Middleware statistics including specifics about the file, the total number of initial measurements or device events processed, the number of initial measurement or device events errors, and total processing time

•

Initial measurement statistics including the number of initial measurements processed

•

Device event statistics including the number of device events processed

•

Payload Error Notification : Contains details concerning processing errors encountered in an individual payload (file) containing one or more initial measurements or device events. Payload Error Notification activities are related to Payload Statistics activities.

•

Payload Summary : Contains processing summary statistics for an individual payload (file) containing one or more initial measurements or device events. Payload Summary activities are related to Payload Statistics activities, and are used to update related payload statistics upon the completion of payload processing.

Upload statistics activities are created during processing of payload files as follows:

•

When processing begins for a payload, a Payload Statistics activity is created to record the process.

•

If an error occurs during processing, a Payload Error Notification activity is created.

•

When payload processing is complete, a Payload Summary activity is created, which in turn, updates the Payload Statistics activity with details concerning the processing of the payload, including the start and end time of the processing, the total processing time, the number of initial measurements or device events processed, and the number of initial measurement or device event errors (if any).

Upload Statistics - XAI Inbound Services

Upload statistics activities are created by the middleware components used by Smart Grid Gatewaty adapters via XAI inbound services. XAI inbound services define the details of how messages are received from an external system, including the activity business object to be invoked when the response message is received. Smart Grid Gateway adapters use a set of XAI inbound services to create upload statistics activities, outlined in the table below:

This type of Upload Statistics Activity...

Is created by this type of

XAI Inbound Service

D1-PayloadStatistics

D1-PayloadStatistics

D1-PayloadSummary

D1-PayloadSummary

D1-PayloadErrorNotif

D1-PayloadErrorNotif

Refer to the Oracle Utilities Application Framework documentation for more information about XAI Inbound Services.

Head-End System Processing Statistics

As Oracle Utilities Smart Grid Gateway processes payloads containing initial measurements or device events, statistics for each payload are captured in Payload Statistics activities. Over time, payload statistics for each head-end system are summarized to allow administrators to view summary statistics for the head-end system. These summarized statistics are referred to as head-end system processing statistics.

Head-end system processing statistics are stored as aggregated measurements for aggregator measuring components. A separate aggregator measuring component must be set up for each head-end system for which processing statistics will be aggregated.

Activities

Activities are used in Oracle Utilities Smart Grid Gateway to record meter commands such as device commissioning/decommissioning, remote connect/disconnect, device status check, or on-demand reading commands. Activities are also used in Oracle Utilities Smart Grid Gateway to track statistics related to uploading initial measurements and device events sent from head-end systems.

Commands

Commands issued to devices, such as remote connect, remote disconnect, and others are defined as activities. These represent commands sent via Oracle Utilities Smart Grid Gateway to devices to invoke a specific type of action.

The table below outlines the commands supported by Oracle Utilities Smart Grid Gateway.

Command

Description

Commission Device

A command issued to establish communication between a device and the head-end system. The goal is to ensure connectivity has been established with the device, that any information needed to communicate with the device has been defined in both Oracle Utilities Smart Grid Gateway and the head-end system, and that the device will begin capturing usage and events.

Decommission Device

A command issued to inform the head-end system when a device needs to be removed from a service point, so that no further reads or events will arrive from the device. Decommissioning is invoked when a device must be removed or deactivated. The goal is to stop any communication between the device and the head-end system.

Device Status Check

A command used to test whether the device is communicating with the network, determine the connection status of the device, and when possible, and check if there are any known malfunctions.

On-Demand Read

A request for the most up-to-date reading from a particular device. These commands are not guaranteed to return immediately. In some cases, completing the command might require a person to manually read the device. The purposes are to check the operational status of the device and/or obtain a more recent reading than is currently available.

Remote Connect

A command issued when a device needs to be connected at a service point.

Remote Disconnect

A command issued when a device needs to be disconnected or shut off at a service point.

Attributes used to define commands include the following:

•

Parent Activity: the parent activity (if any) for the command.

•

Command Effective Date/Time : the date and time on which the command takes effect. Commands issued prior to this date and time remain in the "Waiting for Effective Date" status until this time, at which time the command is executed.

•

Command Expiration Date/Time : the date time when the command expires. The command cannot be executed after this date and time.

•

Priority : the priority for the command.

•

Requester : the application sending the command.

•

Requester User : the user who initiated the command.

•

Requester Transaction ID : an ID for the command, defined by the requester.

•

Utility Device ID : ID of the device used by the utility. Used to derive the device ID if the device ID is not provided.

When a command is initiated, it in turn creates an outbound communication which sends the command request to the head-end system.

Upload Statistics

Upload statistics are statistics related to the uploading of initial measurement data and device events sent from a head-end system, and are defined as activities in the system. This section describes upload statistics and how they are captured and maintained in Oracle Utilities Smart Grid Gateway, including:

•

Upload Statistics Activities

•

Upload Statistics - XAI Inbound Services

•

Head-End System Processing Statistics

Upload Statistics Activities

There are three types of upload statistics activities:

•

Payload Statistics : Contains statistics related to a specific payload (file) containing one or more initial measurements or device events. Payload Statistics activities contain:

•

Basic information about the payload (head-end system, file name, and status)

•

Middleware statistics including specifics about the file, the total number of initial measurements or device events processed, the number of initial measurement or device events errors, and total processing time

•

Initial measurement statistics including the number of initial measurements processed

•

Device event statistics including the number of device events processed

•

Payload Error Notification : Contains details concerning processing errors encountered in an individual payload (file) containing one or more initial measurements or device events. Payload Error Notification activities are related to Payload Statistics activities.

•

Payload Summary : Contains processing summary statistics for an individual payload (file) containing one or more initial measurements or device events. Payload Summary activities are related to Payload Statistics activities, and are used to update related payload statistics upon the completion of payload processing.

Upload statistics activities are created during processing of payload files as follows:

•

When processing begins for a payload, a Payload Statistics activity is created to record the process.

•

If an error occurs during processing, a Payload Error Notification activity is created.

•

When payload processing is complete, a Payload Summary activity is created, which in turn, updates the Payload Statistics activity with details concerning the processing of the payload, including the start and end time of the processing, the total processing time, the number of initial measurements or device events processed, and the number of initial measurement or device event errors (if any).

Upload Statistics - XAI Inbound Services

Upload statistics activities are created by the middleware components used by Smart Grid Gatewaty adapters via XAI inbound services. XAI inbound services define the details of how messages are received from an external system, including the activity business object to be invoked when the response message is received. Smart Grid Gateway adapters use a set of XAI inbound services to create upload statistics activities, outlined in the table below:

This type of Upload Statistics Activity...

Is created by this type of

XAI Inbound Service

D1-PayloadStatistics

D1-PayloadStatistics

D1-PayloadSummary

D1-PayloadSummary

D1-PayloadErrorNotif

D1-PayloadErrorNotif

Refer to the Oracle Utilities Application Framework documentation for more information about XAI Inbound Services.

Head-End System Processing Statistics

As Oracle Utilities Smart Grid Gateway processes payloads containing initial measurements or device events, statistics for each payload are captured in Payload Statistics activities. Over time, payload statistics for each head-end system are summarized to allow administrators to view summary statistics for the head-end system. These summarized statistics are referred to as head-end system processing statistics.

Head-end system processing statistics are stored as aggregated measurements for aggregator measuring components. A separate aggregator measuring component must be set up for each head-end system for which processing statistics will be aggregated.

Communications

Communications are records of messages sent between Oracle Utilities Smart Grid Gateway and an external system, such as a head-end system or edge application as a result of initiating a command for a device. Communications can flow both outbound and inbound. Communications are most often created as a result of a command activity.

Attributes used to define communications include the following:

•

Device ID : the ID of the device related to the communication. All communications (and their related commands) are related to a device.

•

AMI Device Identifier Number : the identifier for the device used by the head-end system.

•

Event Date/Time : the date and time of the message.

•

Command Information : details concerning the command that created the communication, including:

•

Recipient : the recipient of the command (recipients are defined as service providers)

•

Transaction ID : an ID for the command that created the communication.

•

External Transaction ID : ID for the command that created the communication in the external system that sent or received the communication.

•

Event Date/Time : the date and time of the command that created the communication.

See Undestanding the Command Communication Process below for more information about the role of communications in the device communication process.

Outbound Communications

Outbound Communications represent messages sent from Oracle Utilities Smart Grid Gateway to an external system, such as a head-end system or edge application (such as Oracle Customer Care and Billing). Outbound communications use the following types of objects:

•

Outbound Communication Business Objects

•

Outbond Message Types

•

XAI Senders

•

External Systems

Outbound Communication Business Objects

An outbound communication business object must be created for each type of message to be sent to an external system. For head-end systems, this is based on the types of messages the system is designed to accept. For example, suppose a head-end system supports the types of commands outlined above (device commission, device decommission, device status check, on-demand readings, remote connect, and remote disconnect), and that this head-end system accepts a separate type of message for each command. For this example, you would need to create outbound communication business objects for each command, as follows:

Command

Outbound Communication Business Object

Commission Device

Commission Device Outbound Communication

Decommission Device

Decommission Device Outbound Communication

Device Status Check

Device Status Check Outbound Communication

On-Demand Read

On-Demand Read Outbound Communication

Remote Connect

Remote Connect Outbound Communication

Remote Disconnect

Remote Disconnect Outbound Communication

Outbond Message Types

A outbound message type must also be created for each type of message to be sent to an external system. Again, this is based on the types of messages the system is designed to accept. To continue the example above, you might create the following outbound message types:

Command

Outbound Message Type

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read

On-Demand Read

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about outbound message types.

XAI Senders

You must also create an XAI Sender for each type of message to be sent to an external system. XAI senders define the details of how messages are sent to an external system. As in the case of outbound communication business objects and outbound message types, the set of XAI senders you need to create is based on the types of messages the system is designed to accept. To continue the example above, you might create the following XAI senders:

Command

XAI Sender

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read

On-Demand Read

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about XAI senders.

External Systems

You must also create an External System for each external system to which Oracle Utilities Smart Grid Gateway will send messages. Each external system defines a set of outbound message types that will be sent to that system. Each external system outbound message type also specifies the following:

•

The processing method used to send the message (Batch, XAI, or Real-time)

•

The corresponding XAI senders

•

Batch Control (if Processing Method is set to Batch)

•

Message XSL, W3C Schema, and Response XSL (as applicable)

To continue the example above, you might create the following external system:

Head-End System

Outbound Message Type

Processing Method

XAI Sender

Message XSL /Response XSL

Commission Device

Real-time

Commission Device

HES-Request.xsl /

HES-Response.xsl

Decommission Device

Real-time

Decommission Device

HES-Request.xsl /

HES-Response.xsl

Device Status Check

Real-time

Device Status Check

HES-Request.xsl /

HES-Response.xsl

On-Demand Read

Real-time

On-Demand Read

HES-Request.xsl /

HES-Response.xsl

Remote Connect

Real-time

Connect Device

HES-Request.xsl /

HES-Response.xsl

Remote Disconnect

Real-time

Disconnect Device

HES-Request.xsl /

HES-Response.xsl

Refer to the Oracle Utilities Application Framework documentation for more information about external systems.

Inbound Communications

Inbound Communications represent messages sent from a head-end system or edge application (such as Oracle Customer Care and Billing) to Oracle Utilities Smart Grid Gateway. Inbound communications are typically sent in response to a command. Inbound communications use the following types of objects:

•

Inbound Communication Business Objects

•

XAI Inbound Service

Inbound Communication Business Objects

An inbound communication business object must be created for each type of message to be received from an external system. For head-end systems, this is based on the types of messages the system is designed to send. To continue the above example, a head-end system supports the types of commands outlined above (device commission, device decommission, device status check, on-demand readings, remote connect, and remote disconnect), and sends a separate type of message in response to each command. For this example, you would need to create the following inbound communication business objects:

Command Being Responded To

Inbound Communication Business Object

Commission Device

Commission Device Response

Decommission Device

Decommission Device Response

Device Status Check

Device Status Check Response

On-Demand Read

On-Demand Read Response

Remote Connect

Remote Connect Response

Remote Disconnect

Remote Disconnect Response

XAI Inbound Service

You must also create an XAI Inbound Service for each type of message to be received from an external system. XAI inbound services define the details of how messages are received from an external system, including the inbound communication business object (or business service or service script) to be invoked when the response message is received. As in the case of inbound communication business objects, the set of XAI inbound services you need to create is based on the types of messages the system is designed to send. To continue the example above, you might create the following XAI inbound services:

XAI Inbound Service

Schema

(Inbound Communication Business Object)

Commission Device Response

Commission Device Response

Decommission Device Response

Decommission Device Response

Device Status Check Response

Device Status Check Response

On-Demand Read Response

On-Demand Read Response

Connect Device Response

Remote Connect Response

Disconnect Device Response

Remote Disconnect Response

Refer to the Oracle Utilities Application Framework documentation for more information about XAI Inbound Services.

Communications

Communications are records of messages sent between Oracle Utilities Smart Grid Gateway and an external system, such as a head-end system or edge application as a result of initiating a command for a device. Communications can flow both outbound and inbound. Communications are most often created as a result of a command activity.

Attributes used to define communications include the following:

•

Device ID : the ID of the device related to the communication. All communications (and their related commands) are related to a device.

•

AMI Device Identifier Number : the identifier for the device used by the head-end system.

•

Event Date/Time : the date and time of the message.

•

Command Information : details concerning the command that created the communication, including:

•

Recipient : the recipient of the command (recipients are defined as service providers)

•

Transaction ID : an ID for the command that created the communication.

•

External Transaction ID : ID for the command that created the communication in the external system that sent or received the communication.

•

Event Date/Time : the date and time of the command that created the communication.

See Undestanding the Command Communication Process below for more information about the role of communications in the device communication process.

Outbound Communications

Outbound Communications represent messages sent from Oracle Utilities Smart Grid Gateway to an external system, such as a head-end system or edge application (such as Oracle Customer Care and Billing). Outbound communications use the following types of objects:

•

Outbound Communication Business Objects

•

Outbond Message Types

•

XAI Senders

•

External Systems

Outbound Communication Business Objects

An outbound communication business object must be created for each type of message to be sent to an external system. For head-end systems, this is based on the types of messages the system is designed to accept. For example, suppose a head-end system supports the types of commands outlined above (device commission, device decommission, device status check, on-demand readings, remote connect, and remote disconnect), and that this head-end system accepts a separate type of message for each command. For this example, you would need to create outbound communication business objects for each command, as follows:

Command

Outbound Communication Business Object

Commission Device

Commission Device Outbound Communication

Decommission Device

Decommission Device Outbound Communication

Device Status Check

Device Status Check Outbound Communication

On-Demand Read

On-Demand Read Outbound Communication

Remote Connect

Remote Connect Outbound Communication

Remote Disconnect

Remote Disconnect Outbound Communication

Outbond Message Types

A outbound message type must also be created for each type of message to be sent to an external system. Again, this is based on the types of messages the system is designed to accept. To continue the example above, you might create the following outbound message types:

Command

Outbound Message Type

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read

On-Demand Read

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about outbound message types.

XAI Senders

You must also create an XAI Sender for each type of message to be sent to an external system. XAI senders define the details of how messages are sent to an external system. As in the case of outbound communication business objects and outbound message types, the set of XAI senders you need to create is based on the types of messages the system is designed to accept. To continue the example above, you might create the following XAI senders:

Command

XAI Sender

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read

On-Demand Read

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about XAI senders.

External Systems

You must also create an External System for each external system to which Oracle Utilities Smart Grid Gateway will send messages. Each external system defines a set of outbound message types that will be sent to that system. Each external system outbound message type also specifies the following:

•

The processing method used to send the message (Batch, XAI, or Real-time)

•

The corresponding XAI senders

•

Batch Control (if Processing Method is set to Batch)

•

Message XSL, W3C Schema, and Response XSL (as applicable)

To continue the example above, you might create the following external system:

Head-End System

Outbound Message Type

Processing Method

XAI Sender

Message XSL /Response XSL

Commission Device

Real-time

Commission Device

HES-Request.xsl /

HES-Response.xsl

Decommission Device

Real-time

Decommission Device

HES-Request.xsl /

HES-Response.xsl

Device Status Check

Real-time

Device Status Check

HES-Request.xsl /

HES-Response.xsl

On-Demand Read

Real-time

On-Demand Read

HES-Request.xsl /

HES-Response.xsl

Remote Connect

Real-time

Connect Device

HES-Request.xsl /

HES-Response.xsl

Remote Disconnect

Real-time

Disconnect Device

HES-Request.xsl /

HES-Response.xsl

Refer to the Oracle Utilities Application Framework documentation for more information about external systems.

Inbound Communications

Inbound Communications represent messages sent from a head-end system or edge application (such as Oracle Customer Care and Billing) to Oracle Utilities Smart Grid Gateway. Inbound communications are typically sent in response to a command. Inbound communications use the following types of objects:

•

Inbound Communication Business Objects

•

XAI Inbound Service

Inbound Communication Business Objects

An inbound communication business object must be created for each type of message to be received from an external system. For head-end systems, this is based on the types of messages the system is designed to send. To continue the above example, a head-end system supports the types of commands outlined above (device commission, device decommission, device status check, on-demand readings, remote connect, and remote disconnect), and sends a separate type of message in response to each command. For this example, you would need to create the following inbound communication business objects:

Command Being Responded To

Inbound Communication Business Object

Commission Device

Commission Device Response

Decommission Device

Decommission Device Response

Device Status Check

Device Status Check Response

On-Demand Read

On-Demand Read Response

Remote Connect

Remote Connect Response

Remote Disconnect

Remote Disconnect Response

XAI Inbound Service

You must also create an XAI Inbound Service for each type of message to be received from an external system. XAI inbound services define the details of how messages are received from an external system, including the inbound communication business object (or business service or service script) to be invoked when the response message is received. As in the case of inbound communication business objects, the set of XAI inbound services you need to create is based on the types of messages the system is designed to send. To continue the example above, you might create the following XAI inbound services:

XAI Inbound Service

Schema

(Inbound Communication Business Object)

Commission Device Response

Commission Device Response

Decommission Device Response

Decommission Device Response

Device Status Check Response

Device Status Check Response

On-Demand Read Response

On-Demand Read Response

Connect Device Response

Remote Connect Response

Disconnect Device Response

Remote Disconnect Response

Refer to the Oracle Utilities Application Framework documentation for more information about XAI Inbound Services.

Communications

Communications are records of messages sent between Oracle Utilities Smart Grid Gateway and an external system, such as a head-end system or edge application as a result of initiating a command for a device. Communications can flow both outbound and inbound. Communications are most often created as a result of a command activity.

Attributes used to define communications include the following:

•

Device ID : the ID of the device related to the communication. All communications (and their related commands) are related to a device.

•

AMI Device Identifier Number : the identifier for the device used by the head-end system.

•

Event Date/Time : the date and time of the message.

•

Command Information : details concerning the command that created the communication, including:

•

Recipient : the recipient of the command (recipients are defined as service providers)

•

Transaction ID : an ID for the command that created the communication.

•

External Transaction ID : ID for the command that created the communication in the external system that sent or received the communication.

•

Event Date/Time : the date and time of the command that created the communication.

See Undestanding the Command Communication Process below for more information about the role of communications in the device communication process.

Outbound Communications

Outbound Communications represent messages sent from Oracle Utilities Smart Grid Gateway to an external system, such as a head-end system or edge application (such as Oracle Customer Care and Billing). Outbound communications use the following types of objects:

•

Outbound Communication Business Objects

•

Outbond Message Types

•

XAI Senders

•

External Systems

Outbound Communication Business Objects

An outbound communication business object must be created for each type of message to be sent to an external system. For head-end systems, this is based on the types of messages the system is designed to accept. For example, suppose a head-end system supports the types of commands outlined above (device commission, device decommission, device status check, on-demand readings, remote connect, and remote disconnect), and that this head-end system accepts a separate type of message for each command. For this example, you would need to create outbound communication business objects for each command, as follows:

Command

Outbound Communication Business Object

Commission Device

Commission Device Outbound Communication

Decommission Device

Decommission Device Outbound Communication

Device Status Check

Device Status Check Outbound Communication

On-Demand Read

On-Demand Read Outbound Communication

Remote Connect

Remote Connect Outbound Communication

Remote Disconnect

Remote Disconnect Outbound Communication

Outbond Message Types

A outbound message type must also be created for each type of message to be sent to an external system. Again, this is based on the types of messages the system is designed to accept. To continue the example above, you might create the following outbound message types:

Command

Outbound Message Type

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read

On-Demand Read

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about outbound message types.

XAI Senders

You must also create an XAI Sender for each type of message to be sent to an external system. XAI senders define the details of how messages are sent to an external system. As in the case of outbound communication business objects and outbound message types, the set of XAI senders you need to create is based on the types of messages the system is designed to accept. To continue the example above, you might create the following XAI senders:

Command

XAI Sender

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read

On-Demand Read

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about XAI senders.

External Systems

You must also create an External System for each external system to which Oracle Utilities Smart Grid Gateway will send messages. Each external system defines a set of outbound message types that will be sent to that system. Each external system outbound message type also specifies the following:

•

The processing method used to send the message (Batch, XAI, or Real-time)

•

The corresponding XAI senders

•

Batch Control (if Processing Method is set to Batch)

•

Message XSL, W3C Schema, and Response XSL (as applicable)

To continue the example above, you might create the following external system:

Head-End System

Outbound Message Type

Processing Method

XAI Sender

Message XSL /Response XSL

Commission Device

Real-time

Commission Device

HES-Request.xsl /

HES-Response.xsl

Decommission Device

Real-time

Decommission Device

HES-Request.xsl /

HES-Response.xsl

Device Status Check

Real-time

Device Status Check

HES-Request.xsl /

HES-Response.xsl

On-Demand Read

Real-time

On-Demand Read

HES-Request.xsl /

HES-Response.xsl

Remote Connect

Real-time

Connect Device

HES-Request.xsl /

HES-Response.xsl

Remote Disconnect

Real-time

Disconnect Device

HES-Request.xsl /

HES-Response.xsl

Refer to the Oracle Utilities Application Framework documentation for more information about external systems.

Inbound Communications

Inbound Communications represent messages sent from a head-end system or edge application (such as Oracle Customer Care and Billing) to Oracle Utilities Smart Grid Gateway. Inbound communications are typically sent in response to a command. Inbound communications use the following types of objects:

•

Inbound Communication Business Objects

•

XAI Inbound Service

Inbound Communication Business Objects

An inbound communication business object must be created for each type of message to be received from an external system. For head-end systems, this is based on the types of messages the system is designed to send. To continue the above example, a head-end system supports the types of commands outlined above (device commission, device decommission, device status check, on-demand readings, remote connect, and remote disconnect), and sends a separate type of message in response to each command. For this example, you would need to create the following inbound communication business objects:

Command Being Responded To

Inbound Communication Business Object

Commission Device

Commission Device Response

Decommission Device

Decommission Device Response

Device Status Check

Device Status Check Response

On-Demand Read

On-Demand Read Response

Remote Connect

Remote Connect Response

Remote Disconnect

Remote Disconnect Response

XAI Inbound Service

You must also create an XAI Inbound Service for each type of message to be received from an external system. XAI inbound services define the details of how messages are received from an external system, including the inbound communication business object (or business service or service script) to be invoked when the response message is received. As in the case of inbound communication business objects, the set of XAI inbound services you need to create is based on the types of messages the system is designed to send. To continue the example above, you might create the following XAI inbound services:

XAI Inbound Service

Schema

(Inbound Communication Business Object)

Commission Device Response

Commission Device Response

Decommission Device Response

Decommission Device Response

Device Status Check Response

Device Status Check Response

On-Demand Read Response

On-Demand Read Response

Connect Device Response

Remote Connect Response

Disconnect Device Response

Remote Disconnect Response

Refer to the Oracle Utilities Application Framework documentation for more information about XAI Inbound Services.

Completion Events

Completion events are used to create or update data to reflect the effect of an activity or command. Completion events are created upon successful receipt of inbound communications related to an activity or command. For example, a commission device command could result in the creation or update of an install event, while a on-demand read command could result in the creation of an initial measurement.

Attributes used to define completion device events include the following:

•

Activity : the activity (command) that initiated the completion event.

•

Sequence : defines the relative order by which completion events for the activity are executed (in the event that more than one completion event is created for an activity).

•

Inbound Communication : the inbound communication that triggered the completion event.

•

Event Date/Time : the date and time of the completion event.

Several of the commands supported by Oracle Utilities Smart Grid Gateway have related completion events. The table below describes the completion events for each command.

Command

Completion Event

Commission Device

Device Commissioning Completion Event

•

Creates an install event for the device (if one doesn’t exist)

•

Updates the device’s install event status to reflect that the device has been commissioned

Decommission Device

Device Decommissioning Completion Event

•

Updates the device’s install event status to reflect that the device has been decommissioned

On-Demand Read

Create IMD Completion Event

•

Creates an initial measurement for the device

Remote Connect

Connect Device Completion Event

•

Updates the device’s install event status to reflect that the device has been connected

Remote Disconnect

Disconnect Device

•

Updates the device’s install event status to reflect that the device has been disconnected

See Understanding the Command Communication Process below for more information about the role of completion events in the device communication process.

Understanding the Command Communication Process

This section provides an overview of the communication process that takes place when a command is initiated for a device. For each step in the process, the table below provides a brief description of the processing that takes place, and lists the specific objects used by the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr. Refer to the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr Configuration Guide for more details about the configuration objects used by this adapter.

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

Step

Process

Landis+Gyr Adapter Objects

1.

A user initiates a remote connect command for a device.s

A remote connect activity business object is instantiated for the command.

Activity BO: Remote Connect (D1-RemoteConnect)

2.

The remote connect command activity business object creates an outbound communication.

The specific type of outbound communication business object created is determined by the head-end system service provider (based on the processing role defined in the Enter algorithm of the "Awaiting Response" status of the outbound communication business object’s lifecycle.

Outbound Comunication BO: Initiate Connect Disconnect (D3-InitiateConnectDisconnect)

3.

The outbound communication creates an outbound message.

The specific type of outbound message created is determined by the head-end system service provider. (based on the processing role defined in the Enter algorithm of the "Awaiting Response" status of the outbound communication business object’s lifecycle).

Outbound Message Type: Connect Device

(D3-CONNECT)

4.

The outbound message is sent to middleware components via an External System and XAI Sender..

Middleware components utilize Business Process Execution Language (BPEL).

External System: Landis+Gyr Head End System

XAI Sender: Connect Device (D3-Connect)

5.

The middleware converts the outbound message from SGG format into the format used by the head-end system, and sends the message to the head-end system.

6.

When the head-end system sends a response, the middlware receives the response message from the head-end system, and converts it from the format used by the head-end system to SGG format and invokes an XAI Inbound Service.

XAI Inbound Service: D3-ConDisconStChgNotification (D361040925)

7.

The XAI Inbound Service picks up the message, and creates a corresponding inbound communication.

The specific type of inbound communication business object created is determined by the XAI Inbound Service..

XAI Inbound Service: D3-ConDisconStChgNotification (D361040925)

Inbound Communication BO: Connect Disconnect State Changed Notification (Multispeak) (D3-ConnectDisconStateChgNtf)

8.

The inbound communication identifies the parent outbound communication.

Outbound Comunication BO: Initiate Connect Disconnect (D3-InitiateConnectDisconnect)

9.

The inbound communication creates a completion event to update the status of the device to indicate it has been connected.

The specific type of completion event business object created is specified in an Enter algorithm on the "Create Completion Event" Status of the inbound communication business object’s lifecycle.

Completion Event BO: Connect Device (D1-ConnectDevice)

Algorithm: D3-CCE (Create Completion Event)

10.

The inbound communication updates the outbound communication.

This update is performed by an Enter algorithm on the "Completed" Status of the inbound communication business object’s lifecycle.

Outbound Comunication BO: Initiate Connect Disconnect (D3-InitiateConnectDisconnect)

11.

The outbound communication updates the "Connect/Disconnect Completion Flag" and the original activity business object.

This update is performed by an Enter algorithm on the "Completed" Status of the outbound communication business object’s lifecycle.

Outbound Comunication BO: Initiate Connect Disconnect (D3-InitiateConnectDisconnect)

Understanding Bulk Commands

A bulk command is a command that is sent to multiple devices. Examples include using a bulk command to send commissioning commands to a set of meters installed on a particular day, or to send status check commands to a set of meters to verify that power has been restored after an outage. This section describes bulk commands, including:

•

Bulk Command Processing Overview

•

Submitting Bulk Commands Requests

Bulk Command Processing Overview

A bulk command is initiated when an external application or an online user sends a request for a bulk command to a BPEL process. The request contains a collection of meters or devices against which a particular action needs to be taken. BPEL parses the request and sends individual command requests to the Oracle Utilities Service and Measurement Data Foundation for each meter. BPEL also creates a batch request header to track the activities associated with the bulk command. If any failure occurs in the process, a failure notification will be sent to the requesting application. Upon completion, BPEL sends a notification to the Service and Measurement Data Foundation to indicate that the process is completed.

This following table describe bulk command processing in greater detail.

Step

Process

Description

1.

A bulk request is initiated.

Bulk requests can be initiated from an external system or by way of an online request. A bulk request contains the following information:

•

The command to execute

•

The response creation method

•

External IDs for the bulk request and requestor

•

List of devices to which the command should be applied

•

Expiration date/time. This is the date and time after which the commands should be discarded if it has not completed successfully.

2.

A bulk request header is created.

The bulk request header is used to track the status of the individual commands that are linked to the bulk request. It also references the response creation method associated with the request.

3.

Individual commands are created.

A separate command is created for each device listed in the bulk request. Individual commands are linked to their associated bulk request header.

4.

Individual commands are initiated.

The bulk request header is updated to reflect the number of commands successfully initiated. If an individual command is not valid for a specified device, an error is generated for that command.

5.

Individual commands are executed.

Aside from their link to their associated bulk request header, these commands are identical to regular device commands.

6.

Responses are sent to the external system.

In the case of bulk command requests submitted from an external system, as individual commands are completed (when they reach their final state), a response is sent to the external system. The specific manner in which this notification is sent is based on the specified response creation method (see External Request for Bulk Commands for more information).

Submitting Bulk Commands Requests

You can request a bulk command either online, from Oracle Utilities Smart Grid Gateway, or externally, from another application.

External Request for Bulk Commands

When an external application sends a request for a bulk command, a BPEL process parses the bulk request and creates a set of individual commands that are sent to each device listed in the bulk request. This BPEL process also creates the bulk request header that is used to track the progress of the commands and to send one or more responses back to the external application.

The responses are sent according to the response creation method included in the bulk request. The following response creation methods are supported:

•

One-by-One: The commands are processed individually and a response is sent as each command reaches its final state. The external bulk request ID is included on each individual command response that is sent.

•

Wait for All: The commands are processed individually and a response is sent when all of the commands have reached their final state. The first command to reach a final state creates the bulk response, which is updated as each additional command reaches its final state.

•

Timed: The commands are processed individually and a response is sent every x minutes. The first command to reach its final state creates a bulk response. Each additional command to reach its final state during the timed interval updates the bulk response, which is then sent at the end of the interval. This process repeats until all command activities are in their final state, or until the bulk command request expires. The number of minutes for the timed interval is defined on the bulk request header activity type.

When all individual commands are in their final state, the bulk header transitions to its final state. The Activity portal for the bulk header lists information about the bulk command, such as status reasons for discarded commands and command statistics.

Online Request for Bulk Commands

Users can also request a bulk command online from the Device Query portal. When the request is made, the application creates a bulk request header to track the progress of the individual commands sent to the devices. If an individual command is not valid for a particular device, an error is generated for that command. Each individual command is linked to the bulk request header by the activity relationship type flag Online Bulk Request Header. The Activity portal for the bulk header lists information about the bulk command, such as command statistics and status reasons for discarded commands.

Submitting Bulk Commands Requests

You can request a bulk command either online, from Oracle Utilities Smart Grid Gateway, or externally, from another application.

External Request for Bulk Commands

When an external application sends a request for a bulk command, a BPEL process parses the bulk request and creates a set of individual commands that are sent to each device listed in the bulk request. This BPEL process also creates the bulk request header that is used to track the progress of the commands and to send one or more responses back to the external application.

The responses are sent according to the response creation method included in the bulk request. The following response creation methods are supported:

•

One-by-One: The commands are processed individually and a response is sent as each command reaches its final state. The external bulk request ID is included on each individual command response that is sent.

•

Wait for All: The commands are processed individually and a response is sent when all of the commands have reached their final state. The first command to reach a final state creates the bulk response, which is updated as each additional command reaches its final state.

•

Timed: The commands are processed individually and a response is sent every x minutes. The first command to reach its final state creates a bulk response. Each additional command to reach its final state during the timed interval updates the bulk response, which is then sent at the end of the interval. This process repeats until all command activities are in their final state, or until the bulk command request expires. The number of minutes for the timed interval is defined on the bulk request header activity type.

When all individual commands are in their final state, the bulk header transitions to its final state. The Activity portal for the bulk header lists information about the bulk command, such as status reasons for discarded commands and command statistics.

Online Request for Bulk Commands

Users can also request a bulk command online from the Device Query portal. When the request is made, the application creates a bulk request header to track the progress of the individual commands sent to the devices. If an individual command is not valid for a particular device, an error is generated for that command. Each individual command is linked to the bulk request header by the activity relationship type flag Online Bulk Request Header. The Activity portal for the bulk header lists information about the bulk command, such as command statistics and status reasons for discarded commands.

Submitting Bulk Commands Requests

You can request a bulk command either online, from Oracle Utilities Smart Grid Gateway, or externally, from another application.

External Request for Bulk Commands

When an external application sends a request for a bulk command, a BPEL process parses the bulk request and creates a set of individual commands that are sent to each device listed in the bulk request. This BPEL process also creates the bulk request header that is used to track the progress of the commands and to send one or more responses back to the external application.

The responses are sent according to the response creation method included in the bulk request. The following response creation methods are supported:

•

One-by-One: The commands are processed individually and a response is sent as each command reaches its final state. The external bulk request ID is included on each individual command response that is sent.

•

Wait for All: The commands are processed individually and a response is sent when all of the commands have reached their final state. The first command to reach a final state creates the bulk response, which is updated as each additional command reaches its final state.

•

Timed: The commands are processed individually and a response is sent every x minutes. The first command to reach its final state creates a bulk response. Each additional command to reach its final state during the timed interval updates the bulk response, which is then sent at the end of the interval. This process repeats until all command activities are in their final state, or until the bulk command request expires. The number of minutes for the timed interval is defined on the bulk request header activity type.

When all individual commands are in their final state, the bulk header transitions to its final state. The Activity portal for the bulk header lists information about the bulk command, such as status reasons for discarded commands and command statistics.

Online Request for Bulk Commands

Users can also request a bulk command online from the Device Query portal. When the request is made, the application creates a bulk request header to track the progress of the individual commands sent to the devices. If an individual command is not valid for a particular device, an error is generated for that command. Each individual command is linked to the bulk request header by the activity relationship type flag Online Bulk Request Header. The Activity portal for the bulk header lists information about the bulk command, such as command statistics and status reasons for discarded commands.

Understanding Device Events

This section provides an overview of device events and how they are used in the Service and Measurement Data Foundation and related products, including Oracle Utilities Meter Data Management and Oracle Utilities Smart Grid Gateway.

Device Events

Device events are events of some sort that have taken place relative to a device, and can include power outages, power restorations, tampering alerts, command completions, and other events.

Attributes used to define device events include the following:

•

Device Event Date/Time : the date and time of the event. For events with a duration, such as a power outage, this is the start date and time of the duration.

•

Device Event End Date/Time : the end date and time of events with durations (such as power outages). Not applicable to events with no duration, such as a tampering alter or power restoration.

In addition, device events also reference details specific to the head-end system that sent the event, including the following:

•

Sender : the head-end system (defined as a service provider in SGG) from which the event was sent.

•

External Sender ID : the external ID for the head-end system that sent the event.

•

External Event Name : the external, head-end-specific name for the event. This name is translated into a "standard" event name within SGG.

•

External Source Identifier : an identifier for the source of the event.

Standard Event Names

When the system is loading a device event, it first determines which head-end system sent it, and then determines which device produced it. The system then maps the device event name sent by the head-end system to a standard event name that corresponds to the event. Standard event names are beneficial because the event names sent by head-end systems vary, even when the events are essentially the same. What one head-end system calls "Primary Power Down," another system may call "Outage at Endpoint." Creating a standard event name, such as "Power Outage - Device," makes it easier to send the device events to an external system such as Oracle Utilities Meter Data Management. In this way, the external systems that receive the events do not need to be configured to accept all of the possible names for a single type of event.

Standard event names are configured on the Standard Event Name extendable lookup. A standard event name should be configured for each unique business purpose served by the device events that the system receives from the associated head-end systems.

Device Event Mapping

Each head-end-specific event name (which is also called an external event name) that the system will receive from a given head-end should be mapped to a standard event name. This mapping is configured using a device event mapping extendable lookup. Each head-end system should have its own extendable lookup to define event name mapping in order to prevent possible conflicts between mappings. For example, head-end systems A and B might both use the same event name, such as the code "1", but this event might need to be mapped to "outage" for head-end system A but "tamper" for head-end system B.

The device event mapping extendable lookup business object is configurable. Each Oracle Utilities Smart Grid Gateway adapter includes a device event mapping lookup business object for the supported head-end system.

Device Event — Additional Processing

Certain device event business objects can be used to update master data as a result of device events received into the system. For example, when a utility’s field worker arms a meter, the resulting device event can trigger an update to the device’s arming status in the Oracle Utilities application. This processing is initiated by the Executer - Additional Processing system event algorithm during the Additional Processing status of the business object’s lifecycle.

If a standard device event requires additional processing, the algorithms that execute the processing should be specified in the Additional Processing Algorithms list on the Standard Event Name extendable lookup for the event. The base package includes the additional processing algorithm Arm Meter (D1-ARM-METER).

The following base package business objects are configured to execute additional processing:

Business Object Name

Description

D1-DeviceEvtComResp

Device Event Communication Response

Instances of this business object represent communications created in response to device events

D1-PairedEventFirstDeviceEvent

Device Event - Paired Event (First)

Instances of this business object represent individual paired event (first) device events in the system.

D1-PairedEventLastDeviceEvent

Device Event - Paired Event (Last)

Instances of this business object represent individual paired event (last) device events in the system.

D1-StandardDeviceEvent

Standard Device Event

Instances of this business object represent individual standard device events in the system.

Standard vs. Paired Device Events

Some device events represent events that occur without a duration, such as a tampering alert, while other device events represent events with a duration, such as an outage (the duration being the time between the start and end of the outage period.

Device events with no duration are defined using "standard" device event business objects. The Service and Measurement Data Foundation base package provides a sample standard device event business object that can be extended as needed to support implementation-specific requirements. Instances of the standard event business object represent individual device events received into the system.

Device events with a duration are defined using "paired event" business objects, with the first of the pair representing the start of the event, and the last of the pair representing the end of the event. The Service and Measurement Data Foundation base package provides a sample set of paired device event business objects that can be extended as needed to support implementation-specific requirements. Events of this type can be configured to create or complete activities that represent the event. For example, an outage event might create an outage activity that is completed when power is restored. In this example, the outage event would be the first of the pair, while the power restoration event would be the last of the pair.

When pairs of events arrive in rapid succession (such as a last gasp followed quickly by a power restoration), these "paired event" business objects are designed to prevent them from being sent to subscribing applications.

Sending Device Events to Subscribing Systems

When device events are received, they are typically passed onto to another subscribing system, such as Oracle Utilities Meter Data Management, a customer information system (such as Oracle Utilities Customer Care and Billing), an outage system (such as Oracle Utilities Network Management System), or some other application.

The means of sending device event information to subscribing system is defined in the "How to Send Device Event Related Information" processing method for the service provider representing the subscribing system. Device event information can be sent via outbound communication business object, outbound communication, or batch process.

The method for sending device events to subscribing systems (business object, outbound message, or batch process) can be defined for each device event category, and can be overridden for individual device event types (including the ability to exclude specific device event types within a category. In addition, a default event processing method can be also be configured that applies when methods of transmission aren't specified at the individual category level.

The "Subscribe to Device Event" business service is used to process device event subscription requests, and allow external applications to manage the categories of events they receive.

Creating Service Issue Monitors and Service Investigative Orders

Device events can be configured to create service issue monitors and service investigative orders. The service issue monitor type to create is defined on the device event type. When a device event is received, an Enter algorithm on the device event’s Processed state creates the service issue monitor, based on the Service Issue Monitor Type specified for the device event type.

Understanding Device Event Processing

This section provides an overview of the process that takes place when device events are received. For each step in the process, the table below provides a brief description of the processing that takes place, and lists the specific objects used by the Service and Measurement Data Foundation

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

Step

Process

Service and Measurement Data Foundation Objects

1.

The head-end system sends a payload of device events to middleware components. The payload contains both standard and paired device events.

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus. (OSB) as the middleware components for import of usage readings and device events,

2.

The middleware parses the payload into individual device events, and then transforms each from the format used by the head-end system into the SGG format.

3.

The middleware then invokes the Device Event Seeder XAI Inbound Service for each device event. The Device Event Seeder XAI Inbound Service is mapped to the Device Event Seeder business object.

XAI Inbound Service: D1-DeviceEventSeeder (D103879193)

4.

The Device Event Seeder business object determines the type of device event business object to create based on the Device Event Mapping business object (extendable lookup) defined for the head-end system service provider.

Different head-end systems may use different names for the same type of event. This process maps device event names sent by the head-end system to standard device event names.

Processing Method: D1-HowToProcessDeviceInfo (How to Process Device Related Information)

Device Event Mapping BO: D1-DeviceEventMappingLookup

5.

An instance of the appropriate device event business object is created in the system for each device event received.

For paired events, the first event business objects may create activities to represent the event.

Standard Device Event BO: D1-StandardDeviceEvent

Paired (First) Device Event BO: D1-PairedEventFirstDeviceEvent (Device Event - Paired Event (First)

Paired (Last) Device Event BO: D1-PairedEventLastDeviceEvent (Device Event - Paired Event (Last)

6.

If Additional Processing algorithms have been defined for the device event's standard name (in the Standard Event Name extendable lookup), these algorithms are executed when the device event enters the Additional Processing state.

Standard Event Name BO: D1-StdEventNameLookup

7.

If there are systems that subscribe to device events (defined in a processing method for the system service provider), the device event is sent to those systems.

Sending device event information is triggered by an Enter algorithm on the "Processed" Status of the device event business object’s lifecycle.

Note: Sending device event information may involve configuration of XAI senders, outbound message types, and external systems. Refer to the Oracle Utilities Application Framework for more information about using XAI.

Procesing Method: D1-HowToProcDveEvtsInformation (How to Process Device Event Related Info)

Time Zone Translation

If your organization receives device events from a source that provides its data in a different time zone than the one in which the data will be stored in Oracle Utilities Meter Data Management, a translation can be performed to translate the time zone from an external time zone identifier to one configured within the application. This translation is defined via the Head-End Time Zone to Standard Mapping extendable lookup.

Reader Remarks

Reader remarks are a specific type of device event used to capture and/or record specific events or circumstances encountered when a meter reader is manually reading scalar meters. Reader remarks are submitted with scalar initial measurements when received from a head-end system or meter read collection system. Reader remarks are NOT uploaded along with other device events. Reader remarks are ALWAYS associated with a scalar initial measurement. When a reader remark is created, the reader remark type included in the initial measurement determines the type of reader remark created. See Reader Remarks and Scalar Measurements in Chapter 6: Measurement Data for more information about reader remarks.

Device Events

Device events are events of some sort that have taken place relative to a device, and can include power outages, power restorations, tampering alerts, command completions, and other events.

Attributes used to define device events include the following:

•

Device Event Date/Time : the date and time of the event. For events with a duration, such as a power outage, this is the start date and time of the duration.

•

Device Event End Date/Time : the end date and time of events with durations (such as power outages). Not applicable to events with no duration, such as a tampering alter or power restoration.

In addition, device events also reference details specific to the head-end system that sent the event, including the following:

•

Sender : the head-end system (defined as a service provider in SGG) from which the event was sent.

•

External Sender ID : the external ID for the head-end system that sent the event.

•

External Event Name : the external, head-end-specific name for the event. This name is translated into a "standard" event name within SGG.

•

External Source Identifier : an identifier for the source of the event.

Standard Event Names

When the system is loading a device event, it first determines which head-end system sent it, and then determines which device produced it. The system then maps the device event name sent by the head-end system to a standard event name that corresponds to the event. Standard event names are beneficial because the event names sent by head-end systems vary, even when the events are essentially the same. What one head-end system calls "Primary Power Down," another system may call "Outage at Endpoint." Creating a standard event name, such as "Power Outage - Device," makes it easier to send the device events to an external system such as Oracle Utilities Meter Data Management. In this way, the external systems that receive the events do not need to be configured to accept all of the possible names for a single type of event.

Standard event names are configured on the Standard Event Name extendable lookup. A standard event name should be configured for each unique business purpose served by the device events that the system receives from the associated head-end systems.

Device Event Mapping

Each head-end-specific event name (which is also called an external event name) that the system will receive from a given head-end should be mapped to a standard event name. This mapping is configured using a device event mapping extendable lookup. Each head-end system should have its own extendable lookup to define event name mapping in order to prevent possible conflicts between mappings. For example, head-end systems A and B might both use the same event name, such as the code "1", but this event might need to be mapped to "outage" for head-end system A but "tamper" for head-end system B.

The device event mapping extendable lookup business object is configurable. Each Oracle Utilities Smart Grid Gateway adapter includes a device event mapping lookup business object for the supported head-end system.

Device Event — Additional Processing

Certain device event business objects can be used to update master data as a result of device events received into the system. For example, when a utility’s field worker arms a meter, the resulting device event can trigger an update to the device’s arming status in the Oracle Utilities application. This processing is initiated by the Executer - Additional Processing system event algorithm during the Additional Processing status of the business object’s lifecycle.

If a standard device event requires additional processing, the algorithms that execute the processing should be specified in the Additional Processing Algorithms list on the Standard Event Name extendable lookup for the event. The base package includes the additional processing algorithm Arm Meter (D1-ARM-METER).

The following base package business objects are configured to execute additional processing:

Business Object Name

Description

D1-DeviceEvtComResp

Device Event Communication Response

Instances of this business object represent communications created in response to device events

D1-PairedEventFirstDeviceEvent

Device Event - Paired Event (First)

Instances of this business object represent individual paired event (first) device events in the system.

D1-PairedEventLastDeviceEvent

Device Event - Paired Event (Last)

Instances of this business object represent individual paired event (last) device events in the system.

D1-StandardDeviceEvent

Standard Device Event

Instances of this business object represent individual standard device events in the system.

Standard vs. Paired Device Events

Some device events represent events that occur without a duration, such as a tampering alert, while other device events represent events with a duration, such as an outage (the duration being the time between the start and end of the outage period.

Device events with no duration are defined using "standard" device event business objects. The Service and Measurement Data Foundation base package provides a sample standard device event business object that can be extended as needed to support implementation-specific requirements. Instances of the standard event business object represent individual device events received into the system.

Device events with a duration are defined using "paired event" business objects, with the first of the pair representing the start of the event, and the last of the pair representing the end of the event. The Service and Measurement Data Foundation base package provides a sample set of paired device event business objects that can be extended as needed to support implementation-specific requirements. Events of this type can be configured to create or complete activities that represent the event. For example, an outage event might create an outage activity that is completed when power is restored. In this example, the outage event would be the first of the pair, while the power restoration event would be the last of the pair.

When pairs of events arrive in rapid succession (such as a last gasp followed quickly by a power restoration), these "paired event" business objects are designed to prevent them from being sent to subscribing applications.

Sending Device Events to Subscribing Systems

When device events are received, they are typically passed onto to another subscribing system, such as Oracle Utilities Meter Data Management, a customer information system (such as Oracle Utilities Customer Care and Billing), an outage system (such as Oracle Utilities Network Management System), or some other application.

The means of sending device event information to subscribing system is defined in the "How to Send Device Event Related Information" processing method for the service provider representing the subscribing system. Device event information can be sent via outbound communication business object, outbound communication, or batch process.

The method for sending device events to subscribing systems (business object, outbound message, or batch process) can be defined for each device event category, and can be overridden for individual device event types (including the ability to exclude specific device event types within a category. In addition, a default event processing method can be also be configured that applies when methods of transmission aren't specified at the individual category level.

The "Subscribe to Device Event" business service is used to process device event subscription requests, and allow external applications to manage the categories of events they receive.

Creating Service Issue Monitors and Service Investigative Orders

Device events can be configured to create service issue monitors and service investigative orders. The service issue monitor type to create is defined on the device event type. When a device event is received, an Enter algorithm on the device event’s Processed state creates the service issue monitor, based on the Service Issue Monitor Type specified for the device event type.

Understanding Device Event Processing

This section provides an overview of the process that takes place when device events are received. For each step in the process, the table below provides a brief description of the processing that takes place, and lists the specific objects used by the Service and Measurement Data Foundation

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

Step

Process

Service and Measurement Data Foundation Objects

1.

The head-end system sends a payload of device events to middleware components. The payload contains both standard and paired device events.

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus. (OSB) as the middleware components for import of usage readings and device events,

2.

The middleware parses the payload into individual device events, and then transforms each from the format used by the head-end system into the SGG format.

3.

The middleware then invokes the Device Event Seeder XAI Inbound Service for each device event. The Device Event Seeder XAI Inbound Service is mapped to the Device Event Seeder business object.

XAI Inbound Service: D1-DeviceEventSeeder (D103879193)

4.

The Device Event Seeder business object determines the type of device event business object to create based on the Device Event Mapping business object (extendable lookup) defined for the head-end system service provider.

Different head-end systems may use different names for the same type of event. This process maps device event names sent by the head-end system to standard device event names.

Processing Method: D1-HowToProcessDeviceInfo (How to Process Device Related Information)

Device Event Mapping BO: D1-DeviceEventMappingLookup

5.

An instance of the appropriate device event business object is created in the system for each device event received.

For paired events, the first event business objects may create activities to represent the event.

Standard Device Event BO: D1-StandardDeviceEvent

Paired (First) Device Event BO: D1-PairedEventFirstDeviceEvent (Device Event - Paired Event (First)

Paired (Last) Device Event BO: D1-PairedEventLastDeviceEvent (Device Event - Paired Event (Last)

6.

If Additional Processing algorithms have been defined for the device event's standard name (in the Standard Event Name extendable lookup), these algorithms are executed when the device event enters the Additional Processing state.

Standard Event Name BO: D1-StdEventNameLookup

7.

If there are systems that subscribe to device events (defined in a processing method for the system service provider), the device event is sent to those systems.

Sending device event information is triggered by an Enter algorithm on the "Processed" Status of the device event business object’s lifecycle.

Note: Sending device event information may involve configuration of XAI senders, outbound message types, and external systems. Refer to the Oracle Utilities Application Framework for more information about using XAI.

Procesing Method: D1-HowToProcDveEvtsInformation (How to Process Device Event Related Info)

Time Zone Translation

If your organization receives device events from a source that provides its data in a different time zone than the one in which the data will be stored in Oracle Utilities Meter Data Management, a translation can be performed to translate the time zone from an external time zone identifier to one configured within the application. This translation is defined via the Head-End Time Zone to Standard Mapping extendable lookup.

Reader Remarks

Reader remarks are a specific type of device event used to capture and/or record specific events or circumstances encountered when a meter reader is manually reading scalar meters. Reader remarks are submitted with scalar initial measurements when received from a head-end system or meter read collection system. Reader remarks are NOT uploaded along with other device events. Reader remarks are ALWAYS associated with a scalar initial measurement. When a reader remark is created, the reader remark type included in the initial measurement determines the type of reader remark created. See Reader Remarks and Scalar Measurements in Chapter 6: Measurement Data for more information about reader remarks.

Device Events

Device events are events of some sort that have taken place relative to a device, and can include power outages, power restorations, tampering alerts, command completions, and other events.

Attributes used to define device events include the following:

•

Device Event Date/Time : the date and time of the event. For events with a duration, such as a power outage, this is the start date and time of the duration.

•

Device Event End Date/Time : the end date and time of events with durations (such as power outages). Not applicable to events with no duration, such as a tampering alter or power restoration.

In addition, device events also reference details specific to the head-end system that sent the event, including the following:

•

Sender : the head-end system (defined as a service provider in SGG) from which the event was sent.

•

External Sender ID : the external ID for the head-end system that sent the event.

•

External Event Name : the external, head-end-specific name for the event. This name is translated into a "standard" event name within SGG.

•

External Source Identifier : an identifier for the source of the event.

Standard Event Names

When the system is loading a device event, it first determines which head-end system sent it, and then determines which device produced it. The system then maps the device event name sent by the head-end system to a standard event name that corresponds to the event. Standard event names are beneficial because the event names sent by head-end systems vary, even when the events are essentially the same. What one head-end system calls "Primary Power Down," another system may call "Outage at Endpoint." Creating a standard event name, such as "Power Outage - Device," makes it easier to send the device events to an external system such as Oracle Utilities Meter Data Management. In this way, the external systems that receive the events do not need to be configured to accept all of the possible names for a single type of event.

Standard event names are configured on the Standard Event Name extendable lookup. A standard event name should be configured for each unique business purpose served by the device events that the system receives from the associated head-end systems.

Device Event Mapping

Each head-end-specific event name (which is also called an external event name) that the system will receive from a given head-end should be mapped to a standard event name. This mapping is configured using a device event mapping extendable lookup. Each head-end system should have its own extendable lookup to define event name mapping in order to prevent possible conflicts between mappings. For example, head-end systems A and B might both use the same event name, such as the code "1", but this event might need to be mapped to "outage" for head-end system A but "tamper" for head-end system B.

The device event mapping extendable lookup business object is configurable. Each Oracle Utilities Smart Grid Gateway adapter includes a device event mapping lookup business object for the supported head-end system.

Device Event — Additional Processing

Certain device event business objects can be used to update master data as a result of device events received into the system. For example, when a utility’s field worker arms a meter, the resulting device event can trigger an update to the device’s arming status in the Oracle Utilities application. This processing is initiated by the Executer - Additional Processing system event algorithm during the Additional Processing status of the business object’s lifecycle.

If a standard device event requires additional processing, the algorithms that execute the processing should be specified in the Additional Processing Algorithms list on the Standard Event Name extendable lookup for the event. The base package includes the additional processing algorithm Arm Meter (D1-ARM-METER).

The following base package business objects are configured to execute additional processing:

Business Object Name

Description

D1-DeviceEvtComResp

Device Event Communication Response

Instances of this business object represent communications created in response to device events

D1-PairedEventFirstDeviceEvent

Device Event - Paired Event (First)

Instances of this business object represent individual paired event (first) device events in the system.

D1-PairedEventLastDeviceEvent

Device Event - Paired Event (Last)

Instances of this business object represent individual paired event (last) device events in the system.

D1-StandardDeviceEvent

Standard Device Event

Instances of this business object represent individual standard device events in the system.

Standard vs. Paired Device Events

Some device events represent events that occur without a duration, such as a tampering alert, while other device events represent events with a duration, such as an outage (the duration being the time between the start and end of the outage period.

Device events with no duration are defined using "standard" device event business objects. The Service and Measurement Data Foundation base package provides a sample standard device event business object that can be extended as needed to support implementation-specific requirements. Instances of the standard event business object represent individual device events received into the system.

Device events with a duration are defined using "paired event" business objects, with the first of the pair representing the start of the event, and the last of the pair representing the end of the event. The Service and Measurement Data Foundation base package provides a sample set of paired device event business objects that can be extended as needed to support implementation-specific requirements. Events of this type can be configured to create or complete activities that represent the event. For example, an outage event might create an outage activity that is completed when power is restored. In this example, the outage event would be the first of the pair, while the power restoration event would be the last of the pair.

When pairs of events arrive in rapid succession (such as a last gasp followed quickly by a power restoration), these "paired event" business objects are designed to prevent them from being sent to subscribing applications.

Sending Device Events to Subscribing Systems

When device events are received, they are typically passed onto to another subscribing system, such as Oracle Utilities Meter Data Management, a customer information system (such as Oracle Utilities Customer Care and Billing), an outage system (such as Oracle Utilities Network Management System), or some other application.

The means of sending device event information to subscribing system is defined in the "How to Send Device Event Related Information" processing method for the service provider representing the subscribing system. Device event information can be sent via outbound communication business object, outbound communication, or batch process.

The method for sending device events to subscribing systems (business object, outbound message, or batch process) can be defined for each device event category, and can be overridden for individual device event types (including the ability to exclude specific device event types within a category. In addition, a default event processing method can be also be configured that applies when methods of transmission aren't specified at the individual category level.

The "Subscribe to Device Event" business service is used to process device event subscription requests, and allow external applications to manage the categories of events they receive.

Creating Service Issue Monitors and Service Investigative Orders

Device events can be configured to create service issue monitors and service investigative orders. The service issue monitor type to create is defined on the device event type. When a device event is received, an Enter algorithm on the device event’s Processed state creates the service issue monitor, based on the Service Issue Monitor Type specified for the device event type.

Understanding Device Event Processing

This section provides an overview of the process that takes place when device events are received. For each step in the process, the table below provides a brief description of the processing that takes place, and lists the specific objects used by the Service and Measurement Data Foundation

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

Step

Process

Service and Measurement Data Foundation Objects

1.

The head-end system sends a payload of device events to middleware components. The payload contains both standard and paired device events.

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus. (OSB) as the middleware components for import of usage readings and device events,

2.

The middleware parses the payload into individual device events, and then transforms each from the format used by the head-end system into the SGG format.

3.

The middleware then invokes the Device Event Seeder XAI Inbound Service for each device event. The Device Event Seeder XAI Inbound Service is mapped to the Device Event Seeder business object.

XAI Inbound Service: D1-DeviceEventSeeder (D103879193)

4.

The Device Event Seeder business object determines the type of device event business object to create based on the Device Event Mapping business object (extendable lookup) defined for the head-end system service provider.

Different head-end systems may use different names for the same type of event. This process maps device event names sent by the head-end system to standard device event names.

Processing Method: D1-HowToProcessDeviceInfo (How to Process Device Related Information)

Device Event Mapping BO: D1-DeviceEventMappingLookup

5.

An instance of the appropriate device event business object is created in the system for each device event received.

For paired events, the first event business objects may create activities to represent the event.

Standard Device Event BO: D1-StandardDeviceEvent

Paired (First) Device Event BO: D1-PairedEventFirstDeviceEvent (Device Event - Paired Event (First)

Paired (Last) Device Event BO: D1-PairedEventLastDeviceEvent (Device Event - Paired Event (Last)

6.

If Additional Processing algorithms have been defined for the device event's standard name (in the Standard Event Name extendable lookup), these algorithms are executed when the device event enters the Additional Processing state.

Standard Event Name BO: D1-StdEventNameLookup

7.

If there are systems that subscribe to device events (defined in a processing method for the system service provider), the device event is sent to those systems.

Sending device event information is triggered by an Enter algorithm on the "Processed" Status of the device event business object’s lifecycle.

Note: Sending device event information may involve configuration of XAI senders, outbound message types, and external systems. Refer to the Oracle Utilities Application Framework for more information about using XAI.

Procesing Method: D1-HowToProcDveEvtsInformation (How to Process Device Event Related Info)

Time Zone Translation

If your organization receives device events from a source that provides its data in a different time zone than the one in which the data will be stored in Oracle Utilities Meter Data Management, a translation can be performed to translate the time zone from an external time zone identifier to one configured within the application. This translation is defined via the Head-End Time Zone to Standard Mapping extendable lookup.

Reader Remarks

Reader remarks are a specific type of device event used to capture and/or record specific events or circumstances encountered when a meter reader is manually reading scalar meters. Reader remarks are submitted with scalar initial measurements when received from a head-end system or meter read collection system. Reader remarks are NOT uploaded along with other device events. Reader remarks are ALWAYS associated with a scalar initial measurement. When a reader remark is created, the reader remark type included in the initial measurement determines the type of reader remark created. See Reader Remarks and Scalar Measurements in Chapter 6: Measurement Data for more information about reader remarks.

Device Events

Device events are events of some sort that have taken place relative to a device, and can include power outages, power restorations, tampering alerts, command completions, and other events.

Attributes used to define device events include the following:

•

Device Event Date/Time : the date and time of the event. For events with a duration, such as a power outage, this is the start date and time of the duration.

•

Device Event End Date/Time : the end date and time of events with durations (such as power outages). Not applicable to events with no duration, such as a tampering alter or power restoration.

In addition, device events also reference details specific to the head-end system that sent the event, including the following:

•

Sender : the head-end system (defined as a service provider in SGG) from which the event was sent.

•

External Sender ID : the external ID for the head-end system that sent the event.

•

External Event Name : the external, head-end-specific name for the event. This name is translated into a "standard" event name within SGG.

•

External Source Identifier : an identifier for the source of the event.

Standard Event Names

When the system is loading a device event, it first determines which head-end system sent it, and then determines which device produced it. The system then maps the device event name sent by the head-end system to a standard event name that corresponds to the event. Standard event names are beneficial because the event names sent by head-end systems vary, even when the events are essentially the same. What one head-end system calls "Primary Power Down," another system may call "Outage at Endpoint." Creating a standard event name, such as "Power Outage - Device," makes it easier to send the device events to an external system such as Oracle Utilities Meter Data Management. In this way, the external systems that receive the events do not need to be configured to accept all of the possible names for a single type of event.

Standard event names are configured on the Standard Event Name extendable lookup. A standard event name should be configured for each unique business purpose served by the device events that the system receives from the associated head-end systems.

Device Event Mapping

Each head-end-specific event name (which is also called an external event name) that the system will receive from a given head-end should be mapped to a standard event name. This mapping is configured using a device event mapping extendable lookup. Each head-end system should have its own extendable lookup to define event name mapping in order to prevent possible conflicts between mappings. For example, head-end systems A and B might both use the same event name, such as the code "1", but this event might need to be mapped to "outage" for head-end system A but "tamper" for head-end system B.

The device event mapping extendable lookup business object is configurable. Each Oracle Utilities Smart Grid Gateway adapter includes a device event mapping lookup business object for the supported head-end system.

Device Event — Additional Processing

Certain device event business objects can be used to update master data as a result of device events received into the system. For example, when a utility’s field worker arms a meter, the resulting device event can trigger an update to the device’s arming status in the Oracle Utilities application. This processing is initiated by the Executer - Additional Processing system event algorithm during the Additional Processing status of the business object’s lifecycle.

If a standard device event requires additional processing, the algorithms that execute the processing should be specified in the Additional Processing Algorithms list on the Standard Event Name extendable lookup for the event. The base package includes the additional processing algorithm Arm Meter (D1-ARM-METER).

The following base package business objects are configured to execute additional processing:

Business Object Name

Description

D1-DeviceEvtComResp

Device Event Communication Response

Instances of this business object represent communications created in response to device events

D1-PairedEventFirstDeviceEvent

Device Event - Paired Event (First)

Instances of this business object represent individual paired event (first) device events in the system.

D1-PairedEventLastDeviceEvent

Device Event - Paired Event (Last)

Instances of this business object represent individual paired event (last) device events in the system.

D1-StandardDeviceEvent

Standard Device Event

Instances of this business object represent individual standard device events in the system.

Standard vs. Paired Device Events

Some device events represent events that occur without a duration, such as a tampering alert, while other device events represent events with a duration, such as an outage (the duration being the time between the start and end of the outage period.

Device events with no duration are defined using "standard" device event business objects. The Service and Measurement Data Foundation base package provides a sample standard device event business object that can be extended as needed to support implementation-specific requirements. Instances of the standard event business object represent individual device events received into the system.

Device events with a duration are defined using "paired event" business objects, with the first of the pair representing the start of the event, and the last of the pair representing the end of the event. The Service and Measurement Data Foundation base package provides a sample set of paired device event business objects that can be extended as needed to support implementation-specific requirements. Events of this type can be configured to create or complete activities that represent the event. For example, an outage event might create an outage activity that is completed when power is restored. In this example, the outage event would be the first of the pair, while the power restoration event would be the last of the pair.

When pairs of events arrive in rapid succession (such as a last gasp followed quickly by a power restoration), these "paired event" business objects are designed to prevent them from being sent to subscribing applications.

Sending Device Events to Subscribing Systems

When device events are received, they are typically passed onto to another subscribing system, such as Oracle Utilities Meter Data Management, a customer information system (such as Oracle Utilities Customer Care and Billing), an outage system (such as Oracle Utilities Network Management System), or some other application.

The means of sending device event information to subscribing system is defined in the "How to Send Device Event Related Information" processing method for the service provider representing the subscribing system. Device event information can be sent via outbound communication business object, outbound communication, or batch process.

The method for sending device events to subscribing systems (business object, outbound message, or batch process) can be defined for each device event category, and can be overridden for individual device event types (including the ability to exclude specific device event types within a category. In addition, a default event processing method can be also be configured that applies when methods of transmission aren't specified at the individual category level.

The "Subscribe to Device Event" business service is used to process device event subscription requests, and allow external applications to manage the categories of events they receive.

Creating Service Issue Monitors and Service Investigative Orders

Device events can be configured to create service issue monitors and service investigative orders. The service issue monitor type to create is defined on the device event type. When a device event is received, an Enter algorithm on the device event’s Processed state creates the service issue monitor, based on the Service Issue Monitor Type specified for the device event type.

Understanding Device Event Processing

This section provides an overview of the process that takes place when device events are received. For each step in the process, the table below provides a brief description of the processing that takes place, and lists the specific objects used by the Service and Measurement Data Foundation

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

Step

Process

Service and Measurement Data Foundation Objects

1.

The head-end system sends a payload of device events to middleware components. The payload contains both standard and paired device events.

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus. (OSB) as the middleware components for import of usage readings and device events,

2.

The middleware parses the payload into individual device events, and then transforms each from the format used by the head-end system into the SGG format.

3.

The middleware then invokes the Device Event Seeder XAI Inbound Service for each device event. The Device Event Seeder XAI Inbound Service is mapped to the Device Event Seeder business object.

XAI Inbound Service: D1-DeviceEventSeeder (D103879193)

4.

The Device Event Seeder business object determines the type of device event business object to create based on the Device Event Mapping business object (extendable lookup) defined for the head-end system service provider.

Different head-end systems may use different names for the same type of event. This process maps device event names sent by the head-end system to standard device event names.

Processing Method: D1-HowToProcessDeviceInfo (How to Process Device Related Information)

Device Event Mapping BO: D1-DeviceEventMappingLookup

5.

An instance of the appropriate device event business object is created in the system for each device event received.

For paired events, the first event business objects may create activities to represent the event.

Standard Device Event BO: D1-StandardDeviceEvent

Paired (First) Device Event BO: D1-PairedEventFirstDeviceEvent (Device Event - Paired Event (First)

Paired (Last) Device Event BO: D1-PairedEventLastDeviceEvent (Device Event - Paired Event (Last)

6.

If Additional Processing algorithms have been defined for the device event's standard name (in the Standard Event Name extendable lookup), these algorithms are executed when the device event enters the Additional Processing state.

Standard Event Name BO: D1-StdEventNameLookup

7.

If there are systems that subscribe to device events (defined in a processing method for the system service provider), the device event is sent to those systems.

Sending device event information is triggered by an Enter algorithm on the "Processed" Status of the device event business object’s lifecycle.

Note: Sending device event information may involve configuration of XAI senders, outbound message types, and external systems. Refer to the Oracle Utilities Application Framework for more information about using XAI.

Procesing Method: D1-HowToProcDveEvtsInformation (How to Process Device Event Related Info)

Time Zone Translation

If your organization receives device events from a source that provides its data in a different time zone than the one in which the data will be stored in Oracle Utilities Meter Data Management, a translation can be performed to translate the time zone from an external time zone identifier to one configured within the application. This translation is defined via the Head-End Time Zone to Standard Mapping extendable lookup.

Reader Remarks

Reader remarks are a specific type of device event used to capture and/or record specific events or circumstances encountered when a meter reader is manually reading scalar meters. Reader remarks are submitted with scalar initial measurements when received from a head-end system or meter read collection system. Reader remarks are NOT uploaded along with other device events. Reader remarks are ALWAYS associated with a scalar initial measurement. When a reader remark is created, the reader remark type included in the initial measurement determines the type of reader remark created. See Reader Remarks and Scalar Measurements in Chapter 6: Measurement Data for more information about reader remarks.

Device Events

Device events are events of some sort that have taken place relative to a device, and can include power outages, power restorations, tampering alerts, command completions, and other events.

Attributes used to define device events include the following:

•

Device Event Date/Time : the date and time of the event. For events with a duration, such as a power outage, this is the start date and time of the duration.

•

Device Event End Date/Time : the end date and time of events with durations (such as power outages). Not applicable to events with no duration, such as a tampering alter or power restoration.

In addition, device events also reference details specific to the head-end system that sent the event, including the following:

•

Sender : the head-end system (defined as a service provider in SGG) from which the event was sent.

•

External Sender ID : the external ID for the head-end system that sent the event.

•

External Event Name : the external, head-end-specific name for the event. This name is translated into a "standard" event name within SGG.

•

External Source Identifier : an identifier for the source of the event.

Standard Event Names

When the system is loading a device event, it first determines which head-end system sent it, and then determines which device produced it. The system then maps the device event name sent by the head-end system to a standard event name that corresponds to the event. Standard event names are beneficial because the event names sent by head-end systems vary, even when the events are essentially the same. What one head-end system calls "Primary Power Down," another system may call "Outage at Endpoint." Creating a standard event name, such as "Power Outage - Device," makes it easier to send the device events to an external system such as Oracle Utilities Meter Data Management. In this way, the external systems that receive the events do not need to be configured to accept all of the possible names for a single type of event.

Standard event names are configured on the Standard Event Name extendable lookup. A standard event name should be configured for each unique business purpose served by the device events that the system receives from the associated head-end systems.

Device Event Mapping

Each head-end-specific event name (which is also called an external event name) that the system will receive from a given head-end should be mapped to a standard event name. This mapping is configured using a device event mapping extendable lookup. Each head-end system should have its own extendable lookup to define event name mapping in order to prevent possible conflicts between mappings. For example, head-end systems A and B might both use the same event name, such as the code "1", but this event might need to be mapped to "outage" for head-end system A but "tamper" for head-end system B.

The device event mapping extendable lookup business object is configurable. Each Oracle Utilities Smart Grid Gateway adapter includes a device event mapping lookup business object for the supported head-end system.

Device Event — Additional Processing

Certain device event business objects can be used to update master data as a result of device events received into the system. For example, when a utility’s field worker arms a meter, the resulting device event can trigger an update to the device’s arming status in the Oracle Utilities application. This processing is initiated by the Executer - Additional Processing system event algorithm during the Additional Processing status of the business object’s lifecycle.

If a standard device event requires additional processing, the algorithms that execute the processing should be specified in the Additional Processing Algorithms list on the Standard Event Name extendable lookup for the event. The base package includes the additional processing algorithm Arm Meter (D1-ARM-METER).

The following base package business objects are configured to execute additional processing:

Business Object Name

Description

D1-DeviceEvtComResp

Device Event Communication Response

Instances of this business object represent communications created in response to device events

D1-PairedEventFirstDeviceEvent

Device Event - Paired Event (First)

Instances of this business object represent individual paired event (first) device events in the system.

D1-PairedEventLastDeviceEvent

Device Event - Paired Event (Last)

Instances of this business object represent individual paired event (last) device events in the system.

D1-StandardDeviceEvent

Standard Device Event

Instances of this business object represent individual standard device events in the system.

Standard vs. Paired Device Events

Some device events represent events that occur without a duration, such as a tampering alert, while other device events represent events with a duration, such as an outage (the duration being the time between the start and end of the outage period.

Device events with no duration are defined using "standard" device event business objects. The Service and Measurement Data Foundation base package provides a sample standard device event business object that can be extended as needed to support implementation-specific requirements. Instances of the standard event business object represent individual device events received into the system.

Device events with a duration are defined using "paired event" business objects, with the first of the pair representing the start of the event, and the last of the pair representing the end of the event. The Service and Measurement Data Foundation base package provides a sample set of paired device event business objects that can be extended as needed to support implementation-specific requirements. Events of this type can be configured to create or complete activities that represent the event. For example, an outage event might create an outage activity that is completed when power is restored. In this example, the outage event would be the first of the pair, while the power restoration event would be the last of the pair.

When pairs of events arrive in rapid succession (such as a last gasp followed quickly by a power restoration), these "paired event" business objects are designed to prevent them from being sent to subscribing applications.

Sending Device Events to Subscribing Systems

When device events are received, they are typically passed onto to another subscribing system, such as Oracle Utilities Meter Data Management, a customer information system (such as Oracle Utilities Customer Care and Billing), an outage system (such as Oracle Utilities Network Management System), or some other application.

The means of sending device event information to subscribing system is defined in the "How to Send Device Event Related Information" processing method for the service provider representing the subscribing system. Device event information can be sent via outbound communication business object, outbound communication, or batch process.

The method for sending device events to subscribing systems (business object, outbound message, or batch process) can be defined for each device event category, and can be overridden for individual device event types (including the ability to exclude specific device event types within a category. In addition, a default event processing method can be also be configured that applies when methods of transmission aren't specified at the individual category level.

The "Subscribe to Device Event" business service is used to process device event subscription requests, and allow external applications to manage the categories of events they receive.

Creating Service Issue Monitors and Service Investigative Orders

Device events can be configured to create service issue monitors and service investigative orders. The service issue monitor type to create is defined on the device event type. When a device event is received, an Enter algorithm on the device event’s Processed state creates the service issue monitor, based on the Service Issue Monitor Type specified for the device event type.

Understanding Device Event Processing

This section provides an overview of the process that takes place when device events are received. For each step in the process, the table below provides a brief description of the processing that takes place, and lists the specific objects used by the Service and Measurement Data Foundation

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

Step

Process

Service and Measurement Data Foundation Objects

1.

The head-end system sends a payload of device events to middleware components. The payload contains both standard and paired device events.

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus. (OSB) as the middleware components for import of usage readings and device events,

2.

The middleware parses the payload into individual device events, and then transforms each from the format used by the head-end system into the SGG format.

3.

The middleware then invokes the Device Event Seeder XAI Inbound Service for each device event. The Device Event Seeder XAI Inbound Service is mapped to the Device Event Seeder business object.

XAI Inbound Service: D1-DeviceEventSeeder (D103879193)

4.

The Device Event Seeder business object determines the type of device event business object to create based on the Device Event Mapping business object (extendable lookup) defined for the head-end system service provider.

Different head-end systems may use different names for the same type of event. This process maps device event names sent by the head-end system to standard device event names.

Processing Method: D1-HowToProcessDeviceInfo (How to Process Device Related Information)

Device Event Mapping BO: D1-DeviceEventMappingLookup

5.

An instance of the appropriate device event business object is created in the system for each device event received.

For paired events, the first event business objects may create activities to represent the event.

Standard Device Event BO: D1-StandardDeviceEvent

Paired (First) Device Event BO: D1-PairedEventFirstDeviceEvent (Device Event - Paired Event (First)

Paired (Last) Device Event BO: D1-PairedEventLastDeviceEvent (Device Event - Paired Event (Last)

6.

If Additional Processing algorithms have been defined for the device event's standard name (in the Standard Event Name extendable lookup), these algorithms are executed when the device event enters the Additional Processing state.

Standard Event Name BO: D1-StdEventNameLookup

7.

If there are systems that subscribe to device events (defined in a processing method for the system service provider), the device event is sent to those systems.

Sending device event information is triggered by an Enter algorithm on the "Processed" Status of the device event business object’s lifecycle.

Note: Sending device event information may involve configuration of XAI senders, outbound message types, and external systems. Refer to the Oracle Utilities Application Framework for more information about using XAI.

Procesing Method: D1-HowToProcDveEvtsInformation (How to Process Device Event Related Info)

Time Zone Translation

If your organization receives device events from a source that provides its data in a different time zone than the one in which the data will be stored in Oracle Utilities Meter Data Management, a translation can be performed to translate the time zone from an external time zone identifier to one configured within the application. This translation is defined via the Head-End Time Zone to Standard Mapping extendable lookup.

Reader Remarks

Reader remarks are a specific type of device event used to capture and/or record specific events or circumstances encountered when a meter reader is manually reading scalar meters. Reader remarks are submitted with scalar initial measurements when received from a head-end system or meter read collection system. Reader remarks are NOT uploaded along with other device events. Reader remarks are ALWAYS associated with a scalar initial measurement. When a reader remark is created, the reader remark type included in the initial measurement determines the type of reader remark created. See Reader Remarks and Scalar Measurements in Chapter 6: Measurement Data for more information about reader remarks.

Device Events

Device events are events of some sort that have taken place relative to a device, and can include power outages, power restorations, tampering alerts, command completions, and other events.

Attributes used to define device events include the following:

•

Device Event Date/Time : the date and time of the event. For events with a duration, such as a power outage, this is the start date and time of the duration.

•

Device Event End Date/Time : the end date and time of events with durations (such as power outages). Not applicable to events with no duration, such as a tampering alter or power restoration.

In addition, device events also reference details specific to the head-end system that sent the event, including the following:

•

Sender : the head-end system (defined as a service provider in SGG) from which the event was sent.

•

External Sender ID : the external ID for the head-end system that sent the event.

•

External Event Name : the external, head-end-specific name for the event. This name is translated into a "standard" event name within SGG.

•

External Source Identifier : an identifier for the source of the event.

Standard Event Names

When the system is loading a device event, it first determines which head-end system sent it, and then determines which device produced it. The system then maps the device event name sent by the head-end system to a standard event name that corresponds to the event. Standard event names are beneficial because the event names sent by head-end systems vary, even when the events are essentially the same. What one head-end system calls "Primary Power Down," another system may call "Outage at Endpoint." Creating a standard event name, such as "Power Outage - Device," makes it easier to send the device events to an external system such as Oracle Utilities Meter Data Management. In this way, the external systems that receive the events do not need to be configured to accept all of the possible names for a single type of event.

Standard event names are configured on the Standard Event Name extendable lookup. A standard event name should be configured for each unique business purpose served by the device events that the system receives from the associated head-end systems.

Device Event Mapping

Each head-end-specific event name (which is also called an external event name) that the system will receive from a given head-end should be mapped to a standard event name. This mapping is configured using a device event mapping extendable lookup. Each head-end system should have its own extendable lookup to define event name mapping in order to prevent possible conflicts between mappings. For example, head-end systems A and B might both use the same event name, such as the code "1", but this event might need to be mapped to "outage" for head-end system A but "tamper" for head-end system B.

The device event mapping extendable lookup business object is configurable. Each Oracle Utilities Smart Grid Gateway adapter includes a device event mapping lookup business object for the supported head-end system.

Device Event — Additional Processing

Certain device event business objects can be used to update master data as a result of device events received into the system. For example, when a utility’s field worker arms a meter, the resulting device event can trigger an update to the device’s arming status in the Oracle Utilities application. This processing is initiated by the Executer - Additional Processing system event algorithm during the Additional Processing status of the business object’s lifecycle.

If a standard device event requires additional processing, the algorithms that execute the processing should be specified in the Additional Processing Algorithms list on the Standard Event Name extendable lookup for the event. The base package includes the additional processing algorithm Arm Meter (D1-ARM-METER).

The following base package business objects are configured to execute additional processing:

Business Object Name

Description

D1-DeviceEvtComResp

Device Event Communication Response

Instances of this business object represent communications created in response to device events

D1-PairedEventFirstDeviceEvent

Device Event - Paired Event (First)

Instances of this business object represent individual paired event (first) device events in the system.

D1-PairedEventLastDeviceEvent

Device Event - Paired Event (Last)

Instances of this business object represent individual paired event (last) device events in the system.

D1-StandardDeviceEvent

Standard Device Event

Instances of this business object represent individual standard device events in the system.

Standard vs. Paired Device Events

Some device events represent events that occur without a duration, such as a tampering alert, while other device events represent events with a duration, such as an outage (the duration being the time between the start and end of the outage period.

Device events with no duration are defined using "standard" device event business objects. The Service and Measurement Data Foundation base package provides a sample standard device event business object that can be extended as needed to support implementation-specific requirements. Instances of the standard event business object represent individual device events received into the system.

Device events with a duration are defined using "paired event" business objects, with the first of the pair representing the start of the event, and the last of the pair representing the end of the event. The Service and Measurement Data Foundation base package provides a sample set of paired device event business objects that can be extended as needed to support implementation-specific requirements. Events of this type can be configured to create or complete activities that represent the event. For example, an outage event might create an outage activity that is completed when power is restored. In this example, the outage event would be the first of the pair, while the power restoration event would be the last of the pair.

When pairs of events arrive in rapid succession (such as a last gasp followed quickly by a power restoration), these "paired event" business objects are designed to prevent them from being sent to subscribing applications.

Sending Device Events to Subscribing Systems

When device events are received, they are typically passed onto to another subscribing system, such as Oracle Utilities Meter Data Management, a customer information system (such as Oracle Utilities Customer Care and Billing), an outage system (such as Oracle Utilities Network Management System), or some other application.

The means of sending device event information to subscribing system is defined in the "How to Send Device Event Related Information" processing method for the service provider representing the subscribing system. Device event information can be sent via outbound communication business object, outbound communication, or batch process.

The method for sending device events to subscribing systems (business object, outbound message, or batch process) can be defined for each device event category, and can be overridden for individual device event types (including the ability to exclude specific device event types within a category. In addition, a default event processing method can be also be configured that applies when methods of transmission aren't specified at the individual category level.

The "Subscribe to Device Event" business service is used to process device event subscription requests, and allow external applications to manage the categories of events they receive.

Creating Service Issue Monitors and Service Investigative Orders

Device events can be configured to create service issue monitors and service investigative orders. The service issue monitor type to create is defined on the device event type. When a device event is received, an Enter algorithm on the device event’s Processed state creates the service issue monitor, based on the Service Issue Monitor Type specified for the device event type.

Understanding Device Event Processing

This section provides an overview of the process that takes place when device events are received. For each step in the process, the table below provides a brief description of the processing that takes place, and lists the specific objects used by the Service and Measurement Data Foundation

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

Step

Process

Service and Measurement Data Foundation Objects

1.

The head-end system sends a payload of device events to middleware components. The payload contains both standard and paired device events.

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus. (OSB) as the middleware components for import of usage readings and device events,

2.

The middleware parses the payload into individual device events, and then transforms each from the format used by the head-end system into the SGG format.

3.

The middleware then invokes the Device Event Seeder XAI Inbound Service for each device event. The Device Event Seeder XAI Inbound Service is mapped to the Device Event Seeder business object.

XAI Inbound Service: D1-DeviceEventSeeder (D103879193)

4.

The Device Event Seeder business object determines the type of device event business object to create based on the Device Event Mapping business object (extendable lookup) defined for the head-end system service provider.

Different head-end systems may use different names for the same type of event. This process maps device event names sent by the head-end system to standard device event names.

Processing Method: D1-HowToProcessDeviceInfo (How to Process Device Related Information)

Device Event Mapping BO: D1-DeviceEventMappingLookup

5.

An instance of the appropriate device event business object is created in the system for each device event received.

For paired events, the first event business objects may create activities to represent the event.

Standard Device Event BO: D1-StandardDeviceEvent

Paired (First) Device Event BO: D1-PairedEventFirstDeviceEvent (Device Event - Paired Event (First)

Paired (Last) Device Event BO: D1-PairedEventLastDeviceEvent (Device Event - Paired Event (Last)

6.

If Additional Processing algorithms have been defined for the device event's standard name (in the Standard Event Name extendable lookup), these algorithms are executed when the device event enters the Additional Processing state.

Standard Event Name BO: D1-StdEventNameLookup

7.

If there are systems that subscribe to device events (defined in a processing method for the system service provider), the device event is sent to those systems.

Sending device event information is triggered by an Enter algorithm on the "Processed" Status of the device event business object’s lifecycle.

Note: Sending device event information may involve configuration of XAI senders, outbound message types, and external systems. Refer to the Oracle Utilities Application Framework for more information about using XAI.

Procesing Method: D1-HowToProcDveEvtsInformation (How to Process Device Event Related Info)

Time Zone Translation

If your organization receives device events from a source that provides its data in a different time zone than the one in which the data will be stored in Oracle Utilities Meter Data Management, a translation can be performed to translate the time zone from an external time zone identifier to one configured within the application. This translation is defined via the Head-End Time Zone to Standard Mapping extendable lookup.

Reader Remarks

Reader remarks are a specific type of device event used to capture and/or record specific events or circumstances encountered when a meter reader is manually reading scalar meters. Reader remarks are submitted with scalar initial measurements when received from a head-end system or meter read collection system. Reader remarks are NOT uploaded along with other device events. Reader remarks are ALWAYS associated with a scalar initial measurement. When a reader remark is created, the reader remark type included in the initial measurement determines the type of reader remark created. See Reader Remarks and Scalar Measurements in Chapter 6: Measurement Data for more information about reader remarks.

Device Events

Device events are events of some sort that have taken place relative to a device, and can include power outages, power restorations, tampering alerts, command completions, and other events.

Attributes used to define device events include the following:

•

Device Event Date/Time : the date and time of the event. For events with a duration, such as a power outage, this is the start date and time of the duration.

•

Device Event End Date/Time : the end date and time of events with durations (such as power outages). Not applicable to events with no duration, such as a tampering alter or power restoration.

In addition, device events also reference details specific to the head-end system that sent the event, including the following:

•

Sender : the head-end system (defined as a service provider in SGG) from which the event was sent.

•

External Sender ID : the external ID for the head-end system that sent the event.

•

External Event Name : the external, head-end-specific name for the event. This name is translated into a "standard" event name within SGG.

•

External Source Identifier : an identifier for the source of the event.

Standard Event Names

When the system is loading a device event, it first determines which head-end system sent it, and then determines which device produced it. The system then maps the device event name sent by the head-end system to a standard event name that corresponds to the event. Standard event names are beneficial because the event names sent by head-end systems vary, even when the events are essentially the same. What one head-end system calls "Primary Power Down," another system may call "Outage at Endpoint." Creating a standard event name, such as "Power Outage - Device," makes it easier to send the device events to an external system such as Oracle Utilities Meter Data Management. In this way, the external systems that receive the events do not need to be configured to accept all of the possible names for a single type of event.

Standard event names are configured on the Standard Event Name extendable lookup. A standard event name should be configured for each unique business purpose served by the device events that the system receives from the associated head-end systems.

Device Event Mapping

Each head-end-specific event name (which is also called an external event name) that the system will receive from a given head-end should be mapped to a standard event name. This mapping is configured using a device event mapping extendable lookup. Each head-end system should have its own extendable lookup to define event name mapping in order to prevent possible conflicts between mappings. For example, head-end systems A and B might both use the same event name, such as the code "1", but this event might need to be mapped to "outage" for head-end system A but "tamper" for head-end system B.

The device event mapping extendable lookup business object is configurable. Each Oracle Utilities Smart Grid Gateway adapter includes a device event mapping lookup business object for the supported head-end system.

Device Event — Additional Processing

Certain device event business objects can be used to update master data as a result of device events received into the system. For example, when a utility’s field worker arms a meter, the resulting device event can trigger an update to the device’s arming status in the Oracle Utilities application. This processing is initiated by the Executer - Additional Processing system event algorithm during the Additional Processing status of the business object’s lifecycle.

If a standard device event requires additional processing, the algorithms that execute the processing should be specified in the Additional Processing Algorithms list on the Standard Event Name extendable lookup for the event. The base package includes the additional processing algorithm Arm Meter (D1-ARM-METER).

The following base package business objects are configured to execute additional processing:

Business Object Name

Description

D1-DeviceEvtComResp

Device Event Communication Response

Instances of this business object represent communications created in response to device events

D1-PairedEventFirstDeviceEvent

Device Event - Paired Event (First)

Instances of this business object represent individual paired event (first) device events in the system.

D1-PairedEventLastDeviceEvent

Device Event - Paired Event (Last)

Instances of this business object represent individual paired event (last) device events in the system.

D1-StandardDeviceEvent

Standard Device Event

Instances of this business object represent individual standard device events in the system.

Standard vs. Paired Device Events

Some device events represent events that occur without a duration, such as a tampering alert, while other device events represent events with a duration, such as an outage (the duration being the time between the start and end of the outage period.

Device events with no duration are defined using "standard" device event business objects. The Service and Measurement Data Foundation base package provides a sample standard device event business object that can be extended as needed to support implementation-specific requirements. Instances of the standard event business object represent individual device events received into the system.

Device events with a duration are defined using "paired event" business objects, with the first of the pair representing the start of the event, and the last of the pair representing the end of the event. The Service and Measurement Data Foundation base package provides a sample set of paired device event business objects that can be extended as needed to support implementation-specific requirements. Events of this type can be configured to create or complete activities that represent the event. For example, an outage event might create an outage activity that is completed when power is restored. In this example, the outage event would be the first of the pair, while the power restoration event would be the last of the pair.

When pairs of events arrive in rapid succession (such as a last gasp followed quickly by a power restoration), these "paired event" business objects are designed to prevent them from being sent to subscribing applications.

Sending Device Events to Subscribing Systems

When device events are received, they are typically passed onto to another subscribing system, such as Oracle Utilities Meter Data Management, a customer information system (such as Oracle Utilities Customer Care and Billing), an outage system (such as Oracle Utilities Network Management System), or some other application.

The means of sending device event information to subscribing system is defined in the "How to Send Device Event Related Information" processing method for the service provider representing the subscribing system. Device event information can be sent via outbound communication business object, outbound communication, or batch process.

The method for sending device events to subscribing systems (business object, outbound message, or batch process) can be defined for each device event category, and can be overridden for individual device event types (including the ability to exclude specific device event types within a category. In addition, a default event processing method can be also be configured that applies when methods of transmission aren't specified at the individual category level.

The "Subscribe to Device Event" business service is used to process device event subscription requests, and allow external applications to manage the categories of events they receive.

Creating Service Issue Monitors and Service Investigative Orders

Device events can be configured to create service issue monitors and service investigative orders. The service issue monitor type to create is defined on the device event type. When a device event is received, an Enter algorithm on the device event’s Processed state creates the service issue monitor, based on the Service Issue Monitor Type specified for the device event type.

Understanding Device Event Processing

This section provides an overview of the process that takes place when device events are received. For each step in the process, the table below provides a brief description of the processing that takes place, and lists the specific objects used by the Service and Measurement Data Foundation

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

Step

Process

Service and Measurement Data Foundation Objects

1.

The head-end system sends a payload of device events to middleware components. The payload contains both standard and paired device events.

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus. (OSB) as the middleware components for import of usage readings and device events,

2.

The middleware parses the payload into individual device events, and then transforms each from the format used by the head-end system into the SGG format.

3.

The middleware then invokes the Device Event Seeder XAI Inbound Service for each device event. The Device Event Seeder XAI Inbound Service is mapped to the Device Event Seeder business object.

XAI Inbound Service: D1-DeviceEventSeeder (D103879193)

4.

The Device Event Seeder business object determines the type of device event business object to create based on the Device Event Mapping business object (extendable lookup) defined for the head-end system service provider.

Different head-end systems may use different names for the same type of event. This process maps device event names sent by the head-end system to standard device event names.

Processing Method: D1-HowToProcessDeviceInfo (How to Process Device Related Information)

Device Event Mapping BO: D1-DeviceEventMappingLookup

5.

An instance of the appropriate device event business object is created in the system for each device event received.

For paired events, the first event business objects may create activities to represent the event.

Standard Device Event BO: D1-StandardDeviceEvent

Paired (First) Device Event BO: D1-PairedEventFirstDeviceEvent (Device Event - Paired Event (First)

Paired (Last) Device Event BO: D1-PairedEventLastDeviceEvent (Device Event - Paired Event (Last)

6.

If Additional Processing algorithms have been defined for the device event's standard name (in the Standard Event Name extendable lookup), these algorithms are executed when the device event enters the Additional Processing state.

Standard Event Name BO: D1-StdEventNameLookup

7.

If there are systems that subscribe to device events (defined in a processing method for the system service provider), the device event is sent to those systems.

Sending device event information is triggered by an Enter algorithm on the "Processed" Status of the device event business object’s lifecycle.

Note: Sending device event information may involve configuration of XAI senders, outbound message types, and external systems. Refer to the Oracle Utilities Application Framework for more information about using XAI.

Procesing Method: D1-HowToProcDveEvtsInformation (How to Process Device Event Related Info)

Time Zone Translation

If your organization receives device events from a source that provides its data in a different time zone than the one in which the data will be stored in Oracle Utilities Meter Data Management, a translation can be performed to translate the time zone from an external time zone identifier to one configured within the application. This translation is defined via the Head-End Time Zone to Standard Mapping extendable lookup.

Reader Remarks

Reader remarks are a specific type of device event used to capture and/or record specific events or circumstances encountered when a meter reader is manually reading scalar meters. Reader remarks are submitted with scalar initial measurements when received from a head-end system or meter read collection system. Reader remarks are NOT uploaded along with other device events. Reader remarks are ALWAYS associated with a scalar initial measurement. When a reader remark is created, the reader remark type included in the initial measurement determines the type of reader remark created. See Reader Remarks and Scalar Measurements in Chapter 6: Measurement Data for more information about reader remarks.

Device Events

Device events are events of some sort that have taken place relative to a device, and can include power outages, power restorations, tampering alerts, command completions, and other events.

Attributes used to define device events include the following:

•

Device Event Date/Time : the date and time of the event. For events with a duration, such as a power outage, this is the start date and time of the duration.

•

Device Event End Date/Time : the end date and time of events with durations (such as power outages). Not applicable to events with no duration, such as a tampering alter or power restoration.

In addition, device events also reference details specific to the head-end system that sent the event, including the following:

•

Sender : the head-end system (defined as a service provider in SGG) from which the event was sent.

•

External Sender ID : the external ID for the head-end system that sent the event.

•

External Event Name : the external, head-end-specific name for the event. This name is translated into a "standard" event name within SGG.

•

External Source Identifier : an identifier for the source of the event.

Standard Event Names

When the system is loading a device event, it first determines which head-end system sent it, and then determines which device produced it. The system then maps the device event name sent by the head-end system to a standard event name that corresponds to the event. Standard event names are beneficial because the event names sent by head-end systems vary, even when the events are essentially the same. What one head-end system calls "Primary Power Down," another system may call "Outage at Endpoint." Creating a standard event name, such as "Power Outage - Device," makes it easier to send the device events to an external system such as Oracle Utilities Meter Data Management. In this way, the external systems that receive the events do not need to be configured to accept all of the possible names for a single type of event.

Standard event names are configured on the Standard Event Name extendable lookup. A standard event name should be configured for each unique business purpose served by the device events that the system receives from the associated head-end systems.

Device Event Mapping

Each head-end-specific event name (which is also called an external event name) that the system will receive from a given head-end should be mapped to a standard event name. This mapping is configured using a device event mapping extendable lookup. Each head-end system should have its own extendable lookup to define event name mapping in order to prevent possible conflicts between mappings. For example, head-end systems A and B might both use the same event name, such as the code "1", but this event might need to be mapped to "outage" for head-end system A but "tamper" for head-end system B.

The device event mapping extendable lookup business object is configurable. Each Oracle Utilities Smart Grid Gateway adapter includes a device event mapping lookup business object for the supported head-end system.

Device Event — Additional Processing

Certain device event business objects can be used to update master data as a result of device events received into the system. For example, when a utility’s field worker arms a meter, the resulting device event can trigger an update to the device’s arming status in the Oracle Utilities application. This processing is initiated by the Executer - Additional Processing system event algorithm during the Additional Processing status of the business object’s lifecycle.

If a standard device event requires additional processing, the algorithms that execute the processing should be specified in the Additional Processing Algorithms list on the Standard Event Name extendable lookup for the event. The base package includes the additional processing algorithm Arm Meter (D1-ARM-METER).

The following base package business objects are configured to execute additional processing:

Business Object Name

Description

D1-DeviceEvtComResp

Device Event Communication Response

Instances of this business object represent communications created in response to device events

D1-PairedEventFirstDeviceEvent

Device Event - Paired Event (First)

Instances of this business object represent individual paired event (first) device events in the system.

D1-PairedEventLastDeviceEvent

Device Event - Paired Event (Last)

Instances of this business object represent individual paired event (last) device events in the system.

D1-StandardDeviceEvent

Standard Device Event

Instances of this business object represent individual standard device events in the system.

Standard vs. Paired Device Events

Some device events represent events that occur without a duration, such as a tampering alert, while other device events represent events with a duration, such as an outage (the duration being the time between the start and end of the outage period.

Device events with no duration are defined using "standard" device event business objects. The Service and Measurement Data Foundation base package provides a sample standard device event business object that can be extended as needed to support implementation-specific requirements. Instances of the standard event business object represent individual device events received into the system.

Device events with a duration are defined using "paired event" business objects, with the first of the pair representing the start of the event, and the last of the pair representing the end of the event. The Service and Measurement Data Foundation base package provides a sample set of paired device event business objects that can be extended as needed to support implementation-specific requirements. Events of this type can be configured to create or complete activities that represent the event. For example, an outage event might create an outage activity that is completed when power is restored. In this example, the outage event would be the first of the pair, while the power restoration event would be the last of the pair.

When pairs of events arrive in rapid succession (such as a last gasp followed quickly by a power restoration), these "paired event" business objects are designed to prevent them from being sent to subscribing applications.

Sending Device Events to Subscribing Systems

When device events are received, they are typically passed onto to another subscribing system, such as Oracle Utilities Meter Data Management, a customer information system (such as Oracle Utilities Customer Care and Billing), an outage system (such as Oracle Utilities Network Management System), or some other application.

The means of sending device event information to subscribing system is defined in the "How to Send Device Event Related Information" processing method for the service provider representing the subscribing system. Device event information can be sent via outbound communication business object, outbound communication, or batch process.

The method for sending device events to subscribing systems (business object, outbound message, or batch process) can be defined for each device event category, and can be overridden for individual device event types (including the ability to exclude specific device event types within a category. In addition, a default event processing method can be also be configured that applies when methods of transmission aren't specified at the individual category level.

The "Subscribe to Device Event" business service is used to process device event subscription requests, and allow external applications to manage the categories of events they receive.

Creating Service Issue Monitors and Service Investigative Orders

Device events can be configured to create service issue monitors and service investigative orders. The service issue monitor type to create is defined on the device event type. When a device event is received, an Enter algorithm on the device event’s Processed state creates the service issue monitor, based on the Service Issue Monitor Type specified for the device event type.

Understanding Device Event Processing

This section provides an overview of the process that takes place when device events are received. For each step in the process, the table below provides a brief description of the processing that takes place, and lists the specific objects used by the Service and Measurement Data Foundation

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

Step

Process

Service and Measurement Data Foundation Objects

1.

The head-end system sends a payload of device events to middleware components. The payload contains both standard and paired device events.

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus. (OSB) as the middleware components for import of usage readings and device events,

2.

The middleware parses the payload into individual device events, and then transforms each from the format used by the head-end system into the SGG format.

3.

The middleware then invokes the Device Event Seeder XAI Inbound Service for each device event. The Device Event Seeder XAI Inbound Service is mapped to the Device Event Seeder business object.

XAI Inbound Service: D1-DeviceEventSeeder (D103879193)

4.

The Device Event Seeder business object determines the type of device event business object to create based on the Device Event Mapping business object (extendable lookup) defined for the head-end system service provider.

Different head-end systems may use different names for the same type of event. This process maps device event names sent by the head-end system to standard device event names.

Processing Method: D1-HowToProcessDeviceInfo (How to Process Device Related Information)

Device Event Mapping BO: D1-DeviceEventMappingLookup

5.

An instance of the appropriate device event business object is created in the system for each device event received.

For paired events, the first event business objects may create activities to represent the event.

Standard Device Event BO: D1-StandardDeviceEvent

Paired (First) Device Event BO: D1-PairedEventFirstDeviceEvent (Device Event - Paired Event (First)

Paired (Last) Device Event BO: D1-PairedEventLastDeviceEvent (Device Event - Paired Event (Last)

6.

If Additional Processing algorithms have been defined for the device event's standard name (in the Standard Event Name extendable lookup), these algorithms are executed when the device event enters the Additional Processing state.

Standard Event Name BO: D1-StdEventNameLookup

7.

If there are systems that subscribe to device events (defined in a processing method for the system service provider), the device event is sent to those systems.

Sending device event information is triggered by an Enter algorithm on the "Processed" Status of the device event business object’s lifecycle.

Note: Sending device event information may involve configuration of XAI senders, outbound message types, and external systems. Refer to the Oracle Utilities Application Framework for more information about using XAI.

Procesing Method: D1-HowToProcDveEvtsInformation (How to Process Device Event Related Info)

Time Zone Translation

If your organization receives device events from a source that provides its data in a different time zone than the one in which the data will be stored in Oracle Utilities Meter Data Management, a translation can be performed to translate the time zone from an external time zone identifier to one configured within the application. This translation is defined via the Head-End Time Zone to Standard Mapping extendable lookup.

Reader Remarks

Reader remarks are a specific type of device event used to capture and/or record specific events or circumstances encountered when a meter reader is manually reading scalar meters. Reader remarks are submitted with scalar initial measurements when received from a head-end system or meter read collection system. Reader remarks are NOT uploaded along with other device events. Reader remarks are ALWAYS associated with a scalar initial measurement. When a reader remark is created, the reader remark type included in the initial measurement determines the type of reader remark created. See Reader Remarks and Scalar Measurements in Chapter 6: Measurement Data for more information about reader remarks.

Activities In Detail

This section provides details concerning the activity objects supplied as part of the base package. This information illustrates how the base package objects were designed, and can serve as the basis for any custom activity objects you create as part of your implementation. This section includes:

•

A description of the D1-ACTIVITY maintenance object

•

Lists of the base package activity business objects

•

Details concerning activity-specific configuration options

•

A sample activity business object (D1-DeviceWithDurationActivity)

Maintenance Object - D1-ACTIVITY

Activity business objects use the D1-ACTIVITY maintenance object. The table below outlines some of the details of this maintenance object.

Option/Field

Description

Maintenance Object

D1-ACTIVITY

Description

Activity

Service Name

D1-ACTIVITY (Activity Maintenance)

Tables

•

D1_ACTIVITY (Activity) - Primary

•

D1_ACTIVITY_CHAR (Activity Characteristics) - Child

•

D1_ACTIVITY_LOG (Activity Log) - Child

•

D1_ACTIVITY_LOG_PARM (Activity Log Parameter) - Child

•

D1_ACTIVITY_REL (Activity Relationship) - Child

•

D1_ACTIVITY_REL_OBJ (Activity Related Object) - Child

•

D1_ACTIVITY_IDENTIFIER (Activity Identifier) - Child

Use the Maintenance Object portal and the Application Viewer to view more details about this maintenance object.

Service and Measurement Data Foundation Base Package Activity Business Objects

The Service and Measurement Data Foundation base package includes the following activity business objects:

Business Object Name

Description

D1-DeviceWithDurationActivity

Outage Activity with Duration

Instances of this business object represent individual outage activities (triggered by outage device events) in the system.

D1-DeviceWithDurationActParent

Device Activity with Duration Parent (used a parent for device activity with duration business objects)

D1-MeterReadDownloadActivity

Meter Read Download Activity

Instances of this business object represent individual meter read downloads in the system.

D1-UTCorrectnPrcessrActvity

Usage Transaction Correction Processor

Instances of this business object are created via Initial Measurement Data (IMD) processing when the IMD being processed may have resulted in a change to one or more usage transactions for usage subscriptions linked to the measuring component's device via one of its service points.

The Service and Measurement Data Foundation base package includes the following "lite" activity business objects:

Business Object Name

Description

D1-ActivityBIBOToRead

Activity BI BO To Read

D1-ActivityLite

Activity LITE

D1-ActivityParentLite

Activity Parent LITE

Example Activity - D1-DeviceWithDurationActivity

The table below lists the details of the D1-DeviceWithDurationActivity activity business object.

Option

Description

Business Object

D1-DeviceWithDurationActivity

Description

Outage Activity with Duration

Maintenance Object

D1-ACTIVITY (Activity)

Parent Business Object

D1-DeviceWithDurationActParent

Application Service

D1-DVCWITHDURATNBOAS (Device Activity with Duration BO)

Instance Control

Allow New Instances

Options

•

Related Administration BO: D1-DeviceWithDurationActType (Device Activity with Duration Type)

•

Display UI Map: D1-DvcWithDuratnActivityDisp (Outage Activity with Duration - Display)

•

Portal Navigation Option: d1ActivityNavOpt (Activity Navigation Option)

•

Display Map Service Script: D1-RtDDADtls (Device Activity with Duration - Retreive Details for Display)

•

Maintenance UI Map: D1-DvcWithDuratnActivityMaint (Outage Activity with Duration- Maintenance)

Algorithms

(Inherited from parent business object)

•

Information: D1-DDACINFO (Device Activity with Duration Information)

•

Pre-Processing: D1-DETACTTYP (Determine Activity Type)

Lifecycle

(Inherited from parent business object)

•

Pending (Initial)

•

Started (Interim)

•

Ended (Final)

Use the Business Object portal to view additional details concerning this business object.

Smart Grid Gateway Base Package Command Activity Business Objects

The Oracle Utilities Smart Grid Gateway base package includes the following command activity business objects.

Business Object Name

Description

D1-BulkRequestHeader

Bulk Request Header

Instances of this business object represent individual bulk requests headers in the system. Used with bulk commands.

D1-BulkResponse

Bulk Response

Instances of this business object represent individual bulk responses in the system. Used with bulk commands.

D1-CancelCommand

Cancel Command

Instances of this business object represent individual command cancellations in the system.

D1-DeviceCommission

Device Commission

Instances of this business object represent individual device commission commands initiated in the system.

D1-DeviceDecommission

Device Decommission

Instances of this business object represent individual device decommission commands initiated in the system.

D1-DeviceStatusCheck

Device Status Check

Instances of this business object represent individual device status check (ping) commands initiated in the system.

D1-GenericConnect

Generic Connect Device

D1-GenericDisconnect

Generic Disconnect Device

D1-GenericReadDevice

Generic Read Device

D1-MultiDeviceStatusCheck

Multi-Device Status Check

Instances of this business object represent individual multi-device status check (ping) commands initiated in the system

D1-OnDemandReadAbstract

On-Demand Read Abstract Parent (used a a parent for on-demand read activity business objects)

D1-OnDemandReadInterval

On-Demand Read Interval

Instances of this business object represent individual interval on-demand read commands initiated in the system.

D1-OnDemandReadScalar

On-Demand Read Scalar

Instances of this business object represent individual scalar on-demand read commands initiated in the system.

D1-RemoteConnect

Remote Connect

Instances of this business object represent individual remote connect commands initiated in the system.

D1-RemoteDisconnect

Remote Disconnect

Instances of this business object represent individual remote disconnect commands initiated in the system.

Smart Grid Gateway Base Package Payload Statistics Activity Business Objects

The Oracle Utilities Smart Grid Gateway base package includes the following upload statistics activity business objects.

Business Object Name

Description

D1-PayloadErrorNotif

Payload Error Notification

Instances of this business object represent individual payload error notifications in the system.

D1-PayloadExtractScheduler

Payload Extract Scheduler (used a a parent for vendor-specific event and usage extract activity business objects)

D1-PayloadNotification

Payload Notification

Instances of this business object represent individual payload notifications in the system.

D1-PayloadStatistics

Payload Statistics

Instances of this business object represent individual payload statistics in the system.

D1-PayloadSummary

Payload Summary

Instances of this business object represent individual payload statistics summaries in the system.

A Note About License Restrictions

Other activity business objects beyond those listed above are restricted for use with other Oracle Utilities products, and cannot be used without the proper license.

Configuration Options

This section outlines specific types of BO Options used by Oracle Utilities Smart Grid Gateway command activity business objects.

Business Object Options

Command activity business objects used by Oracle Utilities Smart Grid Gateway can make use of the following business object options:

•

Initiate Command Processing Role : This option defines the processing role used to initiate the command for the activity. Valid values are defined as values for the PROC_ROLE_FLG lookup field. The base package includes the following options:

Lookup FIeld Value

Description

D1AM

Obtain AMI Device Identifier

D1DA

Activity Notification

D1DC

Device Commission

D1DD

Device Decommission

D1DM

Device Event Mapping

D1DS

Device Status Check

D1EP

Event Processing Default Configuration

D1FR

Response - Fail

D1IM

Initial Measurement Creation

D1IN

On-Demand Read (Interval)

D1LC

Load Check

D1RC

Remote Connect

D1RD

Remote Disconnect

D1RM

Retrieve Meter

D1RR

Response - Received

D1SC

On-Demand Read (Scalar)

D1SD

Send Device Event

D1SR

Response - Success

D1UM

UOM Mapping

Configuration Options

This section outlines specific types of BO Options used by Oracle Utilities Smart Grid Gateway command activity business objects.

Business Object Options

Command activity business objects used by Oracle Utilities Smart Grid Gateway can make use of the following business object options:

•

Initiate Command Processing Role : This option defines the processing role used to initiate the command for the activity. Valid values are defined as values for the PROC_ROLE_FLG lookup field. The base package includes the following options:

Lookup FIeld Value

Description

D1AM

Obtain AMI Device Identifier

D1DA

Activity Notification

D1DC

Device Commission

D1DD

Device Decommission

D1DM

Device Event Mapping

D1DS

Device Status Check

D1EP

Event Processing Default Configuration

D1FR

Response - Fail

D1IM

Initial Measurement Creation

D1IN

On-Demand Read (Interval)

D1LC

Load Check

D1RC

Remote Connect

D1RD

Remote Disconnect

D1RM

Retrieve Meter

D1RR

Response - Received

D1SC

On-Demand Read (Scalar)

D1SD

Send Device Event

D1SR

Response - Success

D1UM

UOM Mapping

Inbound Communications In Detail

This section provides details concerning the inbound communication objects supplied as part of the base package. This information illustrates how the base package objects were designed, and can serve as the basis for any custom inbound communication objects you create as part of your implementation. This section includes:

•

A description of the D1-COMMIN maintenance object

•

Lists of the base package inbound communication business objects, including "lite" business objects

•

A sample inbound communication business object (D1-CommInLite)

Maintenance Object - D1-COMMIN

Inbound communication business objects use the D1-COMMIN maintenance object. The table below outlines some of the details of this maintenance object.

Option/Field

Description

Maintenance Object

D1-COMMIN

Description

Communication In

Service Name

D1-COMMIN (Communication In Maintenance)

Tables

•

D1_COMM_IN (Communication In) - Primary

•

D1_COMM_IN_CHAR (Communication In Characteristics) - Child

•

D1_COMM_IN_IDENTIFIER (Communication In Identifier) - Child

•

D1_COMM_IN_LOG (Communication In Log) - Child

•

D1_COMM_IN_LOG_PARM (Communication In Log Parameter) - Child

•

D1_COMM_IN_REL_OBJ (Communication In Related Object) - Child

Use the Maintenance Object portal and the Application Viewer to view more details about this maintenance object.

Service and Measurement Data Foundation Base Package Inbound Communication Business Objects

The Service and Measurement Data Foundation base package includes the following "lite" inbound communication business objects:

Business Object Name

Description

D1-CommInLite

Inbound Communication Lite

Oracle Utilities Smart Grid Gateway adapters include vendor-specific inbound communication business objects.

Example Inbound Communication - D1-CommInLite

The table below lists the details of the D1-CommInLite inbound communication business object.

Option

Description

Business Object

D1-CommInLite

Description

Inbound Communication Lite

Maintenance Object

D1-COMMIN (Communication In)

Application Service

F1-DFTAPS (Default Execution Application Service)

Instance Control

Allow New Instances

Use the Business Object portal to view additional details concerning this business object.

Outbound Communications In Detail

This section provides details concerning the outbound communication objects supplied as part of the base package. This information illustrates how the base package objects were designed, and can serve as the basis for any custom outbound communication objects you create as part of your implementation. This section includes:

•

A description of the D1-COMMOUT maintenance object

•

Lists of the base package outbound communication business objects, including "lite" business objects

•

A sample inbound communication business object (D1-CommOutLite)

Maintenance Object - D1-COMMOUT

Inbound communication business objects use the D1-COMMOUT maintenance object. The table below outlines some of the details of this maintenance object.

Option/Field

Description

Maintenance Object

D1-COMMOUT

Description

Communication Out

Service Name

D1-COMMOUT (Communication Out Maintenance)

Tables

•

D1_COMM_OUT (Communication Out) - Primary

•

D1_COMM_OUT_CHAR (Communication Out Characteristics) - Child

•

D1_COMM_OUT_IDENTIFIER (Communication Out Identifier) - Child

•

D1_COMM_OUT_LOG (Communication Out Log) - Child

•

D1_COMM_OUT_LOG_PARM (Communication Out Log Parameter) - Child

•

D1_COMM_OUT_REL_OBJ (Communication Out Related Object) - Child

Use the Maintenance Object portal and the Application Viewer to view more details about this maintenance object.

Service and Measurement Data Foundation Base Package Outbound Communication Business Objects

The Service and Measurement Data Foundation base package includes the following "lite" outbound communication business objects:

Business Object Name

Description

D1-CommOutLite

Outbound Communication Lite

D1-CommOutPlacerBO

Communication Out Placer BO

D1-CommunicationLite

Communication Lite

Oracle Utilities Smart Grid Gateway adapters include vendor-specific outbound communication business objects.

Example Outbound Communication - D1-CommOutLite

The table below lists the details of the D1-CommOutLite outbound communication business object.

Option

Description

Business Object

D1-CommOutLite

Description

Outbound Communication Lite

Maintenance Object

D1-COMMOUT (Communication Out)

Application Service

F1-DFTAPS (Default Execution Application Service)

Instance Control

Allow New Instances

Use the Business Object portal to view additional details concerning this business object.

Bulk Commands in Detail

This section provides details concerning the bulk command objects supplied as part of the base package. This information illustrates how the base package objects were designed, and can serve as the basis for any custom bulk command objects you create as part of your implementation. This section includes:

•

Service and Measurement Data Foundation Base Package Bulk Command Business Objects

•

Example Activity - D1-BulkRequestHeader

•

Bulk Command Options

Service and Measurement Data Foundation Base Package Bulk Command Business Objects

The Service and Measurement Data Foundation base package includes the following activity business objects:

Business Object Name

Description

D1-BulkRequestHeader

The bulk request header business object tracks and coordinates the creation of responses to a set of commands requested for a list of devices. While this BO does not retain the list of devices (since this list can be long), its ID is linked to each individual command. The Bulk Request Header's display map shows the current state of progress of its individual commands.

D1-BulkResponse

The bulk response business object constructs an XML list containing responses to individual commands from a bulk request. An empty bulk response is created by individual commands linked to a bulk request as they are completed or discarded. The bulk request header has the responsibility of transitioning the bulk response to assemble its contents and send its message.

D1-OutboundMessageBulk

The outbound message business object used for sending a response for the bulk command.

Example Activity - D1-BulkRequestHeader

The table below lists the details of the D1-BulkRequestHeader activity business object.

Option

Description

Business Object

D1-BulkRequestHeader

Description

Bulk Request Header

Maintenance Object

D1-ACTIVITY (Activity)

Application Service

D1-BULKREQBOAS (Bulk Request Header BO)

Instance Control

Allow New Instances

Options

•

Related Administration BO: D1-BulkRequestHeaderType (Bulk Request Header Type)

•

Display UI Map: D1-BulkRequestHeaderDisp (Bulk Request Header - Display)

•

Portal Navigation Option: d1ActivityNavOpt (Activity Navigation Option)

•

Display Map Service Script: D1-BuReDtls (Bulk Request Header - Details for Display)

•

Maintenance UI Map: D1-BulkRequestHeaderMaint (Bulk Request Header - Maintenance)

Algorithms

•

Information: D1-CRAINFO (Command Request Activity Information)

•

Pre-Processing: D1-DETACTTYP (Determine Activity Type)

•

Pre-Processing: D1-DMRO (Default Measurement Requested Override)

•

Pre-Processing: D1-VALBULKID (Validate External Bulk Request ID)

•

Validation: D1-BINPVAL (Bulk Request Input Validation

Lifecycle

•

Pending (Initial)

•

Validate (Interim)

•

Validation Error (Interim)

•

Discarded (Interim)

•

Waiting for Effective Date (Interim)

•

Awaiting Completion (Interim)

•

Send Response (Interim)

•

Completed (Final)

Bulk Command Options

This section outlines specific configuration options that are used by bulk command business objects, including:

•

Algorithms

•

Lookups

•

XAI Inbound Services

Algorithms

The base package includes the following algorithms associated with bulk commands

Algorithm

Description

Where Used/Referenced

D1-BINPVAL

Bulk Request Input Validation

Validation algorithm on D1-BulkRequestHeader

D1-BULKCANC

Cancel Outstanding Individual Commands

Enter algorithm on Discarded state and Completed state of D1-BulkRequestHeader

D1-BULKWAIT

Bulk Awaiting Completion

Monitor algorithm on Awaiting Completion state of D1-BulkRequestHeader

D1-CANBULRES

Cancel Outstanding Bulk Responses

Enter algorithm on Discarded state and Completed state of D1-BulkRequestHeader

D1-PREPBULK

Prepare Bulk Response

Enter algorithm on Completed state and Discarded state of device commands.

D1-SENBULCON

Send Bulk Remote Connect Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULDCN

Send Bulk Remote Disconnect Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULDSC

Send Bulk Device Status Check Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULFIM

Send Bulk Final Measurement Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULMES

Send Bulk Message

Enter algorithm on Sending Message state of D1-BulkResponse.

D1-SENBULODR

Send Bulk On-Demand Read Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULRES

Send Outstanding Bulk Responses

Enter algorithm on Send Response state of D1-BulkRequestHeader

D1-SENBULSTM

Send Bulk Start Measurement Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULSUC

Send Bulk Command Success Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-VALBULKID

Validate External Bulk Request ID

Preprocessing algorithm on D1-BulkRequestHeader

Lookups

A monitor algorithm evaluates the response creation option selected on the bulk request activity. The base package includes the following options for the response creation method

Lookup FIeld Value

Description

D1ON

One-by-One

D1TM

Timed

D1WT

Wait for All

XAI Inbound Services

The base package includes the following XAI inbound services associate with bulk commands.

Description

XAI Inbound Service Name

Schema Name

Bulk Request Header

D1-BulkRequestHeader

D1-BulkRequestHeader

Bulk Request Update

D1-BulkRequestUpdate

D1-BULKUPD

Bulk Response

D1-BulkResponse

D1-BulkResponse

Bulk Command Options

This section outlines specific configuration options that are used by bulk command business objects, including:

•

Algorithms

•

Lookups

•

XAI Inbound Services

Algorithms

The base package includes the following algorithms associated with bulk commands

Algorithm

Description

Where Used/Referenced

D1-BINPVAL

Bulk Request Input Validation

Validation algorithm on D1-BulkRequestHeader

D1-BULKCANC

Cancel Outstanding Individual Commands

Enter algorithm on Discarded state and Completed state of D1-BulkRequestHeader

D1-BULKWAIT

Bulk Awaiting Completion

Monitor algorithm on Awaiting Completion state of D1-BulkRequestHeader

D1-CANBULRES

Cancel Outstanding Bulk Responses

Enter algorithm on Discarded state and Completed state of D1-BulkRequestHeader

D1-PREPBULK

Prepare Bulk Response

Enter algorithm on Completed state and Discarded state of device commands.

D1-SENBULCON

Send Bulk Remote Connect Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULDCN

Send Bulk Remote Disconnect Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULDSC

Send Bulk Device Status Check Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULFIM

Send Bulk Final Measurement Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULMES

Send Bulk Message

Enter algorithm on Sending Message state of D1-BulkResponse.

D1-SENBULODR

Send Bulk On-Demand Read Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULRES

Send Outstanding Bulk Responses

Enter algorithm on Send Response state of D1-BulkRequestHeader

D1-SENBULSTM

Send Bulk Start Measurement Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULSUC

Send Bulk Command Success Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-VALBULKID

Validate External Bulk Request ID

Preprocessing algorithm on D1-BulkRequestHeader

Lookups

A monitor algorithm evaluates the response creation option selected on the bulk request activity. The base package includes the following options for the response creation method

Lookup FIeld Value

Description

D1ON

One-by-One

D1TM

Timed

D1WT

Wait for All

XAI Inbound Services

The base package includes the following XAI inbound services associate with bulk commands.

Description

XAI Inbound Service Name

Schema Name

Bulk Request Header

D1-BulkRequestHeader

D1-BulkRequestHeader

Bulk Request Update

D1-BulkRequestUpdate

D1-BULKUPD

Bulk Response

D1-BulkResponse

D1-BulkResponse

Bulk Command Options

This section outlines specific configuration options that are used by bulk command business objects, including:

•

Algorithms

•

Lookups

•

XAI Inbound Services

Algorithms

The base package includes the following algorithms associated with bulk commands

Algorithm

Description

Where Used/Referenced

D1-BINPVAL

Bulk Request Input Validation

Validation algorithm on D1-BulkRequestHeader

D1-BULKCANC

Cancel Outstanding Individual Commands

Enter algorithm on Discarded state and Completed state of D1-BulkRequestHeader

D1-BULKWAIT

Bulk Awaiting Completion

Monitor algorithm on Awaiting Completion state of D1-BulkRequestHeader

D1-CANBULRES

Cancel Outstanding Bulk Responses

Enter algorithm on Discarded state and Completed state of D1-BulkRequestHeader

D1-PREPBULK

Prepare Bulk Response

Enter algorithm on Completed state and Discarded state of device commands.

D1-SENBULCON

Send Bulk Remote Connect Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULDCN

Send Bulk Remote Disconnect Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULDSC

Send Bulk Device Status Check Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULFIM

Send Bulk Final Measurement Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULMES

Send Bulk Message

Enter algorithm on Sending Message state of D1-BulkResponse.

D1-SENBULODR

Send Bulk On-Demand Read Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULRES

Send Outstanding Bulk Responses

Enter algorithm on Send Response state of D1-BulkRequestHeader

D1-SENBULSTM

Send Bulk Start Measurement Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULSUC

Send Bulk Command Success Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-VALBULKID

Validate External Bulk Request ID

Preprocessing algorithm on D1-BulkRequestHeader

Lookups

A monitor algorithm evaluates the response creation option selected on the bulk request activity. The base package includes the following options for the response creation method

Lookup FIeld Value

Description

D1ON

One-by-One

D1TM

Timed

D1WT

Wait for All

XAI Inbound Services

The base package includes the following XAI inbound services associate with bulk commands.

Description

XAI Inbound Service Name

Schema Name

Bulk Request Header

D1-BulkRequestHeader

D1-BulkRequestHeader

Bulk Request Update

D1-BulkRequestUpdate

D1-BULKUPD

Bulk Response

D1-BulkResponse

D1-BulkResponse

Bulk Command Options

This section outlines specific configuration options that are used by bulk command business objects, including:

•

Algorithms

•

Lookups

•

XAI Inbound Services

Algorithms

The base package includes the following algorithms associated with bulk commands

Algorithm

Description

Where Used/Referenced

D1-BINPVAL

Bulk Request Input Validation

Validation algorithm on D1-BulkRequestHeader

D1-BULKCANC

Cancel Outstanding Individual Commands

Enter algorithm on Discarded state and Completed state of D1-BulkRequestHeader

D1-BULKWAIT

Bulk Awaiting Completion

Monitor algorithm on Awaiting Completion state of D1-BulkRequestHeader

D1-CANBULRES

Cancel Outstanding Bulk Responses

Enter algorithm on Discarded state and Completed state of D1-BulkRequestHeader

D1-PREPBULK

Prepare Bulk Response

Enter algorithm on Completed state and Discarded state of device commands.

D1-SENBULCON

Send Bulk Remote Connect Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULDCN

Send Bulk Remote Disconnect Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULDSC

Send Bulk Device Status Check Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULFIM

Send Bulk Final Measurement Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULMES

Send Bulk Message

Enter algorithm on Sending Message state of D1-BulkResponse.

D1-SENBULODR

Send Bulk On-Demand Read Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULRES

Send Outstanding Bulk Responses

Enter algorithm on Send Response state of D1-BulkRequestHeader

D1-SENBULSTM

Send Bulk Start Measurement Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-SENBULSUC

Send Bulk Command Success Response

Enter algorithm on Sending Message state of D1-BulkResponse

D1-VALBULKID

Validate External Bulk Request ID

Preprocessing algorithm on D1-BulkRequestHeader

Lookups

A monitor algorithm evaluates the response creation option selected on the bulk request activity. The base package includes the following options for the response creation method

Lookup FIeld Value

Description

D1ON

One-by-One

D1TM

Timed

D1WT

Wait for All

XAI Inbound Services

The base package includes the following XAI inbound services associate with bulk commands.

Description

XAI Inbound Service Name

Schema Name

Bulk Request Header

D1-BulkRequestHeader

D1-BulkRequestHeader

Bulk Request Update

D1-BulkRequestUpdate

D1-BULKUPD

Bulk Response

D1-BulkResponse

D1-BulkResponse

Completion Events In Detail

This section provides details concerning the completion event objects supplied as part of the base package. This information illustrates how the base package objects were designed, and can serve as the basis for any custom completion event objects you create as part of your implementation. This section includes:

•

A description of the D1-CEVT maintenance object

•

Lists of the base package completion event business objects

•

A sample completion event business object (D1-ConnectDevice)

Maintenance Object - D1-CEVT

Completion event business objects use the D1-CEVT maintenance object. The table below outlines some of the details of this maintenance object.

Option/Field

Description

Maintenance Object

D1-CEVT

Description

Completion Event

Service Name

D1-CEVT (Completion Event Maintenance)

Tables

•

D1_COMPL_EVT (Completion Event) - Primary

•

D1_COMPL_EVT_CHAR (Completion Event Characteristics) - Child

•

D1_COMPL_EVT_LOG (Completion Event Log) - Child

•

D1_COMPL_EVT_LOG_PARM (Completion Event Log Parameters) - Child

•

D1_COMPL_EVT_REL_OBJ (Completion Event Related Objects) - Child

Use the Maintenance Object portal and the Application Viewer to view more details about this maintenance object.

Service and Measurement Data Foundation Base Package Completion Event Business Objects

The Service and Measurement Data Foundation base package includes the following completion event business objects:

Business Object Name

Description

D1-CommissionDevice

Commission Device Completion Event

Instances of this business object represent individual commission device completion events in the system.

D1-CompletionEvent

Completion Event (generic completion event business object used as a parent business object for all other completion event business objects)

D1-ConnectDevice

Connect Device Completion Event

Instances of this business object represent individual connect device completion events in the system.

D1-CreateIMD

Create IMD Completion Event

Instances of this business object represent individual create IMD completion events in the system.

D1-DecommissionDevice

Decommission Device Completion Event

Instances of this business object represent individual decommission device completion events in the system.

D1-DisconnectDevice

Disconnect Device Completion Event

Instances of this business object represent individual disconnect device completion events in the system.

Example Completion Event - D1-ConnectDevice

The table below lists the details of the D1-ConnectDevice completion event business object.

Option

Description

Business Object

D1-ConnectDevice

Description

Connect Device

Maintenance Object

D1-CEVT (Completion Event)

Parent Business Object

D1-CompletionEvent (Completion Event)

Lifecycle Business Object

Completion Event

Application Service

D1-CEVTBOAS (Completion Event BO)

Instance Control

Allow New Instances

Options

•

Display UI Map: D1-ConnectDeviceCEvtDisp (Connect Device Completion Event - Display)

•

Portal Navigation Option: d1cevtTabMenu (Completion Event)

•

Display Map Service Script: D1-D1-CEvtRetDt (Completion Event - Retreive Details for Display)

•

Maintenance UI Map: D1-ConnectDeviceCEvtMaint (Connect Dvc Completion Event - Maintenance)

Algorithms

•

Validation: D1-VALTRCEVT (Validate Transition Completion Events)

Use the Business Object portal to view additional details concerning this business object.

Device Events In Detail

This section provides details concerning the device event objects supplied as part of the base package. This information illustrates how the base package objects were designed, and can serve as the basis for any custom device event objects you create as part of your implementation. This section includes:

•

A description of the D1-DVCEVENT maintenance object

•

Lists of the base package device event business objects, including "lite" business objects

•

A sample device event business object (D1-SmartMeterdeviceEvent)

Maintenance Object - D1-DVCEVENT

Device event business objects use the D1-DVCEVENT maintenance object. The table below outlines some of the details of this maintenance object.

Option/Field

Description

Maintenance Object

D1-DVCEVENT

Description

Device Event

Service Name

D1-DVCEVENT (Device Event Maintenance)

Tables

•

D1_DVC_EVT (Device Event) - Primary

•

D1_DVC_EVT_IDENTIFIER (Device Event Identifier)

•

D1_DVC_EVT_CHAR (Device Event Characteristic) - Child

•

D1_DVC_EVT_LOG (Device Event Log) - Child

•

D1_DVC_EVT_LOG_PARM (Device Event Log Parameter) - Child

•

D1_DVC_EVT_REL_OBJ (Device Event Related Object) - Child

Algorithms

•

Transition Error: D1-GEN-MOERR (MO Transition Error)

Use the Maintenance Object portal and the Application Viewer to view more details about this maintenance object.

Service and Measurement Data Foundation Base Package Device Event Business Objects

The Service and Measurement Data Foundation base package includes the following device event business objects:

Business Object Name

Description

D1-DeviceEvent

Device Event (generic device event business object used as a parent business object for all other device event business objects.

D1-DeviceEventSeeder

Device Event Seeder (used to to determine the device event business object to use when creating new device events)

D1-DeviceEvtComResp

Device Event Communication Response

Instances of this business object represent communications created in response to device events

D1-PairedEventFirstDeviceEvent

Device Event - Paired Event (First)

Instances of this business object represent individual paired event (first) device events in the system.

D1-PairedEventLastDeviceEvent

Device Event - Paired Event (Last)

Instances of this business object represent individual paired event (last) device events in the system.

D1-ReaderRemark

Reader Remark

Instances of this business object represent individual reader remarks in the system. Note that reader remarks are created via import of initial measurement data.

D1-StandardDeviceEvent

Standard Device Event

Instances of this business object represent individual standard device events in the system.

The Service and Measurement Data Foundation base package includes the following "lite" device event business objects:

Business Object Name

Description

D1-DeviceEventBIBOToRead

Device Event BO To Read

Example Device Event - D1-DeviceEvent

The table below lists the details of the D1-DeviceEvent device event business object. Note that this business object is used as a parent business object for other device events business objects.

Option

Description

Business Object

D1-DeviceEvent

Description

Device Event

Maintenance Object

D1-DVCEVENT (Device Event)

Application Service

D1-DEVICEEVENTBOAS (Device Event BO)

Instance Control

Do not allow new instances

Options

None (options are defined for child business objects)

Algorithms

(apply to all child business objects)

•

Information: D1-DEVTINFO (Device Event Info)

•

Validation: D1-VALDVCEVT (Validate Device Event)

•

Validation: D1-VALDEXEVT (Validate External Event Name)

Lifecycle

(apply to all child business objects)

•

Pending (Initial)

•

Additional Processing (Interim)

•

Help (Interim)

•

Discarded (Final)

•

Processed (Final)

Use the Business Object portal to view additional details concerning this business object.

Configuring Activities and Device Events

This section provides high-level overviews of the steps involved in configuring custom activities and device events. See Configuration Process Overview in Chapter One for a high-level overview of the overall configuration process.

Note : The procedures below focus on specific configuration tasks and options related to each of the objects described in this chapter, and do not address all the steps involved in creating business objects, UI maps, algorithms, etc. For more information about these subjects, refer to the Oracle Utilities Application Framework documentation.

Configuring Custom Activities

Configuring custom activities involves the following steps:

1.

Design the activity business objects you will need to create for your implementation, including the data and processing required for each.

2.

Create the custom activity-related configuration objects required for your business objects, including:

3.

Set up admin records that define the activity types you will use in your implementation.

Configuring Custom Device Events

Configuring custom device events involves the following steps:

1.

Design the device event business objects you will need to create for your implementation, including the data and processing required for each.

2.

Create your device event business objects.

Note : Device event business objects should reference D1-DeviceEvent as their Parent Business Object.

Configuring Device Communication and Device Event Objects

This section provides high-level overviews of the steps involved in configuring custom command activities, communications (inbound and outbound), and completion events. See Configuration Process Overview in Chapter One for a high-level overview of the overall configuration process.

Note : The procedures below focus on specific configuration tasks and options related to each of the objects described in this chapter, and do not address all the steps involved in creating business objects, UI maps, algorithms, etc. For more information about these subjects, refer to the Oracle Utilities Application Framework documentation.

Configuring Custom Command Activities

Configuring custom activities involves the following steps:

1.

Design the activity business objects you will need to create for your implementation, including the data and processing required for each.

2.

Create the custom activity-related configuration objects required for your business objects, including:

System Events : Create algorithms for the following system events:

•

Applicable Processing Role(s)

3.

Set up admin records that define the activity types you will use in your implementation.

Configuring Custom Inbound Communications

Configuring custom inbound communications involves the following steps:

1.

Design the inbound communication business objects you will need to create for your implementation, including the data and processing required for each.

2.

Create your inbound communication business objects..

3.

Set up admin records that define the inbound communication types you will use in your implementation.

Configuring Custom Outbound Communications

Configuring custom outbound communications involves the following steps:

1.

Design the outbound communication business objects you will need to create for your implementation, including the data and processing required for each.

2.

Create your outbound communication business objects.

3.

Set up admin records that define the outbound communication types you will use in your implementation.

Configuring Custom Completion Events

Configuring custom completion events involves the following steps:

1.

Design the completion event business objects you will need to create for your implementation, including the data and processing required for each.

2.

Create your completion event business objects.

Note : Completion event business objects should reference D1-CompletionEvent as their Parent Business Object.

Configuring Bulk Command Processing

This section provides high-level overviews of the steps involved in configuring bulk command activities, communications (inbound and outbound), completion events, and device events.

Note : The procedures below focus on specific configuration tasks and options related to each of the objects described in this chapter, and do not address all the steps involved in creating business objects, UI maps, algorithms, etc. For more information about these subjects, refer to the Oracle Utilities Application Framework documentation.

Configuring Service Providers

Configuring a service provider associated with bulk commands involves the following steps:

1.

Create a service provider using the External Application business object. The external system associated with the service provider should be the bulk command external system. See Configuring External Systems for more information.

2.

Add the following processing methods to the service provider:

•

Bulk Response

•

Response - Fail

•

Response - Received

•

Response - Success

Configuring XAI Senders

Configuring the external system involves creating the following outbound message types:

•

Bulk Complete Notification

•

Bulk Received Notification

•

Bulk Response

•

Bulk Response Notification

•

Bulk Response

Configuring External Systems

The external system should have the same name as the service provider. Configuring the external system involves adding the following outbound message types:

•

Bulk Completion Notification

•

Bulk Received Notification

•

Bulk Response Notification

Sending a Bulk Request from an External Application

You can use a BPEL process to send a bulk request from an external application. Use the following values to send the bulk request:

Parameter

Value

WSDL

http:// <SERVER>:<SERVER_PORT>/soa-infra/services/<adapter>*/BulkRequest/BulkRequestService?WSDL

Endpoint URL

http:// <SERVER>:<SERVER_PORT>/soa-infra/services/<adapter>*/BulkRequest/BulkRequestService

*indicates the specific adapter for which bulk commands are being sent.

Input Arguments

The following XML can be used as a sample for the input arguments to the BPEL process. In this example, the response creation method is D1WT (Wait for All). The external system ID should be the same as the service provider:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body xmlns:ns1="http://xmlns.oracle.com/ouaf/ssn">

<ns1:bulkRequest>

<ns1:responseCreationMethod>D1WT</ns1:responseCreationMethod>

<ns1:timedResponseBeforeAllReceived>false</ns1:timedResponseBeforeAllReceived>

<ns1:externalBulkRequestId>ZZ_VK_1003</ns1:externalBulkRequestId>

<ns1:externalRequesterId>ZZBULK_XAI</ns1:externalRequesterId>

<ns1:commandIdentifier>OnDemandReadScalar</ns1:commandIdentifier>

<ns1:utilityDeviceIds>

<ns1:utilityDeviceIdentifierNumber>AM_ODR_SCALAR_01</ns1:utilityDeviceIdentifierNumber>

<ns1:utilityDeviceIdentifierNumber>AM_ODR_SCALAR_02</ns1:utilityDeviceIdentifierNumber>

<ns1:utilityDeviceIdentifierNumber>AM_ODR_SCALAR_03</ns1:utilityDeviceIdentifierNumber>

<ns1:utilityDeviceIdentifierNumber>AM_ODR_SCALAR_04</ns1:utilityDeviceIdentifierNumber>

</ns1:utilityDeviceIds>

<ns1:expirationDateTime></ns1:expirationDateTime>

<ns1:callbackURL></ns1:callbackURL>

</ns1:bulkRequest>

</soap:Body>

</soap:Envelope>

The following table describes the elements in the input arguments:

Element

Description

bulkRequest

Header element that contains a bulk request.

responseCreationMethod

Specifies the method in which responses are created for requests submitted from external systems. Valid values include:

•

One by One (D1ON)

•

Timed (D1TM)

•

Wait for All (D1WT)

timedResponseBeforeAllReceived

Specifies whether or not a response should be sent back to external system before all commands are received. Valid values are:

•

true

•

false

externalBulkRequestId

An ID given by the external system to represent the request.

externalRequesterId

The ID of the external system submitting the request. This must match the External System linked to the Service provider that represents the external system

commandIdentifier

Specifies the command to initiate for the listed devices. Valid values include:

•

DeviceStatusCheck

•

DeviceCommissioning

•

DeviceDecommissioning

•

EnableService

•

OnDemandReadInterval

•

OnDemandReadScalar

•

RemoteConnect

•

RemoteDisconnect

utilityDeviceIds

Element containing one or more utilityDeviceIdentifierNumber elements that specify individual devices for which the specified command is to be initiated.

utilityDeviceIdentifierNumber

The Device Identifier Number for the device for which the specified command is to be initiated.

This value should be based on the "AMI Device ID Type" specified on the Service Provider that represents the external system submitting the request.

expirationDateTime

The date and time after which commands that have not yet completed are discarded

callbackURL

The URL from the external system where information is sent if a fault occurs while processing commands. If empty, no fault information is sent.

Configuring Bulk Command Processing

This section provides high-level overviews of the steps involved in configuring bulk command activities, communications (inbound and outbound), completion events, and device events.

Note : The procedures below focus on specific configuration tasks and options related to each of the objects described in this chapter, and do not address all the steps involved in creating business objects, UI maps, algorithms, etc. For more information about these subjects, refer to the Oracle Utilities Application Framework documentation.

Configuring Service Providers

Configuring a service provider associated with bulk commands involves the following steps:

1.

Create a service provider using the External Application business object. The external system associated with the service provider should be the bulk command external system. See Configuring External Systems for more information.

2.

Add the following processing methods to the service provider:

•

Bulk Response

•

Response - Fail

•

Response - Received

•

Response - Success

Configuring XAI Senders

Configuring the external system involves creating the following outbound message types:

•

Bulk Complete Notification

•

Bulk Received Notification

•

Bulk Response

•

Bulk Response Notification

•

Bulk Response

Configuring External Systems

The external system should have the same name as the service provider. Configuring the external system involves adding the following outbound message types:

•

Bulk Completion Notification

•

Bulk Received Notification

•

Bulk Response Notification

Sending a Bulk Request from an External Application

You can use a BPEL process to send a bulk request from an external application. Use the following values to send the bulk request:

Parameter

Value

WSDL

http:// <SERVER>:<SERVER_PORT>/soa-infra/services/<adapter>*/BulkRequest/BulkRequestService?WSDL

Endpoint URL

http:// <SERVER>:<SERVER_PORT>/soa-infra/services/<adapter>*/BulkRequest/BulkRequestService

*indicates the specific adapter for which bulk commands are being sent.

Input Arguments

The following XML can be used as a sample for the input arguments to the BPEL process. In this example, the response creation method is D1WT (Wait for All). The external system ID should be the same as the service provider:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body xmlns:ns1="http://xmlns.oracle.com/ouaf/ssn">

<ns1:bulkRequest>

<ns1:responseCreationMethod>D1WT</ns1:responseCreationMethod>

<ns1:timedResponseBeforeAllReceived>false</ns1:timedResponseBeforeAllReceived>

<ns1:externalBulkRequestId>ZZ_VK_1003</ns1:externalBulkRequestId>

<ns1:externalRequesterId>ZZBULK_XAI</ns1:externalRequesterId>

<ns1:commandIdentifier>OnDemandReadScalar</ns1:commandIdentifier>

<ns1:utilityDeviceIds>

<ns1:utilityDeviceIdentifierNumber>AM_ODR_SCALAR_01</ns1:utilityDeviceIdentifierNumber>

<ns1:utilityDeviceIdentifierNumber>AM_ODR_SCALAR_02</ns1:utilityDeviceIdentifierNumber>

<ns1:utilityDeviceIdentifierNumber>AM_ODR_SCALAR_03</ns1:utilityDeviceIdentifierNumber>

<ns1:utilityDeviceIdentifierNumber>AM_ODR_SCALAR_04</ns1:utilityDeviceIdentifierNumber>

</ns1:utilityDeviceIds>

<ns1:expirationDateTime></ns1:expirationDateTime>

<ns1:callbackURL></ns1:callbackURL>

</ns1:bulkRequest>

</soap:Body>

</soap:Envelope>

The following table describes the elements in the input arguments:

Element

Description

bulkRequest

Header element that contains a bulk request.

responseCreationMethod

Specifies the method in which responses are created for requests submitted from external systems. Valid values include:

•

One by One (D1ON)

•

Timed (D1TM)

•

Wait for All (D1WT)

timedResponseBeforeAllReceived

Specifies whether or not a response should be sent back to external system before all commands are received. Valid values are:

•

true

•

false

externalBulkRequestId

An ID given by the external system to represent the request.

externalRequesterId

The ID of the external system submitting the request. This must match the External System linked to the Service provider that represents the external system

commandIdentifier

Specifies the command to initiate for the listed devices. Valid values include:

•

DeviceStatusCheck

•

DeviceCommissioning

•

DeviceDecommissioning

•

EnableService

•

OnDemandReadInterval

•

OnDemandReadScalar

•

RemoteConnect

•

RemoteDisconnect

utilityDeviceIds

Element containing one or more utilityDeviceIdentifierNumber elements that specify individual devices for which the specified command is to be initiated.

utilityDeviceIdentifierNumber

The Device Identifier Number for the device for which the specified command is to be initiated.

This value should be based on the "AMI Device ID Type" specified on the Service Provider that represents the external system submitting the request.

expirationDateTime

The date and time after which commands that have not yet completed are discarded

callbackURL

The URL from the external system where information is sent if a fault occurs while processing commands. If empty, no fault information is sent.

Configuring Bulk Command Processing

This section provides high-level overviews of the steps involved in configuring bulk command activities, communications (inbound and outbound), completion events, and device events.

Note : The procedures below focus on specific configuration tasks and options related to each of the objects described in this chapter, and do not address all the steps involved in creating business objects, UI maps, algorithms, etc. For more information about these subjects, refer to the Oracle Utilities Application Framework documentation.

Configuring Service Providers

Configuring a service provider associated with bulk commands involves the following steps:

1.

Create a service provider using the External Application business object. The external system associated with the service provider should be the bulk command external system. See Configuring External Systems for more information.

2.

Add the following processing methods to the service provider:

•

Bulk Response

•

Response - Fail

•

Response - Received

•

Response - Success

Configuring XAI Senders

Configuring the external system involves creating the following outbound message types:

•

Bulk Complete Notification

•

Bulk Received Notification

•

Bulk Response

•

Bulk Response Notification

•

Bulk Response

Configuring External Systems

The external system should have the same name as the service provider. Configuring the external system involves adding the following outbound message types:

•

Bulk Completion Notification

•

Bulk Received Notification

•

Bulk Response Notification

Sending a Bulk Request from an External Application

You can use a BPEL process to send a bulk request from an external application. Use the following values to send the bulk request:

Parameter

Value

WSDL

http:// <SERVER>:<SERVER_PORT>/soa-infra/services/<adapter>*/BulkRequest/BulkRequestService?WSDL

Endpoint URL

http:// <SERVER>:<SERVER_PORT>/soa-infra/services/<adapter>*/BulkRequest/BulkRequestService

*indicates the specific adapter for which bulk commands are being sent.

Input Arguments

The following XML can be used as a sample for the input arguments to the BPEL process. In this example, the response creation method is D1WT (Wait for All). The external system ID should be the same as the service provider:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body xmlns:ns1="http://xmlns.oracle.com/ouaf/ssn">

<ns1:bulkRequest>

<ns1:responseCreationMethod>D1WT</ns1:responseCreationMethod>

<ns1:timedResponseBeforeAllReceived>false</ns1:timedResponseBeforeAllReceived>

<ns1:externalBulkRequestId>ZZ_VK_1003</ns1:externalBulkRequestId>

<ns1:externalRequesterId>ZZBULK_XAI</ns1:externalRequesterId>

<ns1:commandIdentifier>OnDemandReadScalar</ns1:commandIdentifier>

<ns1:utilityDeviceIds>

<ns1:utilityDeviceIdentifierNumber>AM_ODR_SCALAR_01</ns1:utilityDeviceIdentifierNumber>

<ns1:utilityDeviceIdentifierNumber>AM_ODR_SCALAR_02</ns1:utilityDeviceIdentifierNumber>

<ns1:utilityDeviceIdentifierNumber>AM_ODR_SCALAR_03</ns1:utilityDeviceIdentifierNumber>

<ns1:utilityDeviceIdentifierNumber>AM_ODR_SCALAR_04</ns1:utilityDeviceIdentifierNumber>

</ns1:utilityDeviceIds>

<ns1:expirationDateTime></ns1:expirationDateTime>

<ns1:callbackURL></ns1:callbackURL>

</ns1:bulkRequest>

</soap:Body>

</soap:Envelope>

The following table describes the elements in the input arguments:

Element

Description

bulkRequest

Header element that contains a bulk request.

responseCreationMethod

Specifies the method in which responses are created for requests submitted from external systems. Valid values include:

•

One by One (D1ON)

•

Timed (D1TM)

•

Wait for All (D1WT)

timedResponseBeforeAllReceived

Specifies whether or not a response should be sent back to external system before all commands are received. Valid values are:

•

true

•

false

externalBulkRequestId

An ID given by the external system to represent the request.

externalRequesterId

The ID of the external system submitting the request. This must match the External System linked to the Service provider that represents the external system

commandIdentifier

Specifies the command to initiate for the listed devices. Valid values include:

•

DeviceStatusCheck

•

DeviceCommissioning

•

DeviceDecommissioning

•

EnableService

•

OnDemandReadInterval

•

OnDemandReadScalar

•

RemoteConnect

•

RemoteDisconnect

utilityDeviceIds

Element containing one or more utilityDeviceIdentifierNumber elements that specify individual devices for which the specified command is to be initiated.

utilityDeviceIdentifierNumber

The Device Identifier Number for the device for which the specified command is to be initiated.

This value should be based on the "AMI Device ID Type" specified on the Service Provider that represents the external system submitting the request.

expirationDateTime

The date and time after which commands that have not yet completed are discarded

callbackURL

The URL from the external system where information is sent if a fault occurs while processing commands. If empty, no fault information is sent.

Configuring Bulk Command Processing

This section provides high-level overviews of the steps involved in configuring bulk command activities, communications (inbound and outbound), completion events, and device events.

Note : The procedures below focus on specific configuration tasks and options related to each of the objects described in this chapter, and do not address all the steps involved in creating business objects, UI maps, algorithms, etc. For more information about these subjects, refer to the Oracle Utilities Application Framework documentation.

Configuring Service Providers

Configuring a service provider associated with bulk commands involves the following steps:

1.

Create a service provider using the External Application business object. The external system associated with the service provider should be the bulk command external system. See Configuring External Systems for more information.

2.

Add the following processing methods to the service provider:

•

Bulk Response

•

Response - Fail

•

Response - Received

•

Response - Success

Configuring XAI Senders

Configuring the external system involves creating the following outbound message types:

•

Bulk Complete Notification

•

Bulk Received Notification

•

Bulk Response

•

Bulk Response Notification

•

Bulk Response

Configuring External Systems

The external system should have the same name as the service provider. Configuring the external system involves adding the following outbound message types:

•

Bulk Completion Notification

•

Bulk Received Notification

•

Bulk Response Notification

Sending a Bulk Request from an External Application

You can use a BPEL process to send a bulk request from an external application. Use the following values to send the bulk request:

Parameter

Value

WSDL

http:// <SERVER>:<SERVER_PORT>/soa-infra/services/<adapter>*/BulkRequest/BulkRequestService?WSDL

Endpoint URL

http:// <SERVER>:<SERVER_PORT>/soa-infra/services/<adapter>*/BulkRequest/BulkRequestService

*indicates the specific adapter for which bulk commands are being sent.

Input Arguments

The following XML can be used as a sample for the input arguments to the BPEL process. In this example, the response creation method is D1WT (Wait for All). The external system ID should be the same as the service provider:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body xmlns:ns1="http://xmlns.oracle.com/ouaf/ssn">

<ns1:bulkRequest>

<ns1:responseCreationMethod>D1WT</ns1:responseCreationMethod>

<ns1:timedResponseBeforeAllReceived>false</ns1:timedResponseBeforeAllReceived>

<ns1:externalBulkRequestId>ZZ_VK_1003</ns1:externalBulkRequestId>

<ns1:externalRequesterId>ZZBULK_XAI</ns1:externalRequesterId>

<ns1:commandIdentifier>OnDemandReadScalar</ns1:commandIdentifier>

<ns1:utilityDeviceIds>

<ns1:utilityDeviceIdentifierNumber>AM_ODR_SCALAR_01</ns1:utilityDeviceIdentifierNumber>

<ns1:utilityDeviceIdentifierNumber>AM_ODR_SCALAR_02</ns1:utilityDeviceIdentifierNumber>

<ns1:utilityDeviceIdentifierNumber>AM_ODR_SCALAR_03</ns1:utilityDeviceIdentifierNumber>

<ns1:utilityDeviceIdentifierNumber>AM_ODR_SCALAR_04</ns1:utilityDeviceIdentifierNumber>

</ns1:utilityDeviceIds>

<ns1:expirationDateTime></ns1:expirationDateTime>

<ns1:callbackURL></ns1:callbackURL>

</ns1:bulkRequest>

</soap:Body>

</soap:Envelope>

The following table describes the elements in the input arguments:

Element

Description

bulkRequest

Header element that contains a bulk request.

responseCreationMethod

Specifies the method in which responses are created for requests submitted from external systems. Valid values include:

•

One by One (D1ON)

•

Timed (D1TM)

•

Wait for All (D1WT)

timedResponseBeforeAllReceived

Specifies whether or not a response should be sent back to external system before all commands are received. Valid values are:

•

true

•

false

externalBulkRequestId

An ID given by the external system to represent the request.

externalRequesterId

The ID of the external system submitting the request. This must match the External System linked to the Service provider that represents the external system

commandIdentifier

Specifies the command to initiate for the listed devices. Valid values include:

•

DeviceStatusCheck

•

DeviceCommissioning

•

DeviceDecommissioning

•

EnableService

•

OnDemandReadInterval

•

OnDemandReadScalar

•

RemoteConnect

•

RemoteDisconnect

utilityDeviceIds

Element containing one or more utilityDeviceIdentifierNumber elements that specify individual devices for which the specified command is to be initiated.

utilityDeviceIdentifierNumber

The Device Identifier Number for the device for which the specified command is to be initiated.

This value should be based on the "AMI Device ID Type" specified on the Service Provider that represents the external system submitting the request.

expirationDateTime

The date and time after which commands that have not yet completed are discarded

callbackURL

The URL from the external system where information is sent if a fault occurs while processing commands. If empty, no fault information is sent.

Configuring Bulk Command Processing

This section provides high-level overviews of the steps involved in configuring bulk command activities, communications (inbound and outbound), completion events, and device events.

Note : The procedures below focus on specific configuration tasks and options related to each of the objects described in this chapter, and do not address all the steps involved in creating business objects, UI maps, algorithms, etc. For more information about these subjects, refer to the Oracle Utilities Application Framework documentation.

Configuring Service Providers

Configuring a service provider associated with bulk commands involves the following steps:

1.

Create a service provider using the External Application business object. The external system associated with the service provider should be the bulk command external system. See Configuring External Systems for more information.

2.

Add the following processing methods to the service provider:

•

Bulk Response

•

Response - Fail

•

Response - Received

•

Response - Success

Configuring XAI Senders

Configuring the external system involves creating the following outbound message types:

•

Bulk Complete Notification

•

Bulk Received Notification

•

Bulk Response

•

Bulk Response Notification

•

Bulk Response

Configuring External Systems

The external system should have the same name as the service provider. Configuring the external system involves adding the following outbound message types:

•

Bulk Completion Notification

•

Bulk Received Notification

•

Bulk Response Notification

Sending a Bulk Request from an External Application

You can use a BPEL process to send a bulk request from an external application. Use the following values to send the bulk request:

Parameter

Value

WSDL

http:// <SERVER>:<SERVER_PORT>/soa-infra/services/<adapter>*/BulkRequest/BulkRequestService?WSDL

Endpoint URL

http:// <SERVER>:<SERVER_PORT>/soa-infra/services/<adapter>*/BulkRequest/BulkRequestService

*indicates the specific adapter for which bulk commands are being sent.

Input Arguments

The following XML can be used as a sample for the input arguments to the BPEL process. In this example, the response creation method is D1WT (Wait for All). The external system ID should be the same as the service provider:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body xmlns:ns1="http://xmlns.oracle.com/ouaf/ssn">

<ns1:bulkRequest>

<ns1:responseCreationMethod>D1WT</ns1:responseCreationMethod>

<ns1:timedResponseBeforeAllReceived>false</ns1:timedResponseBeforeAllReceived>

<ns1:externalBulkRequestId>ZZ_VK_1003</ns1:externalBulkRequestId>

<ns1:externalRequesterId>ZZBULK_XAI</ns1:externalRequesterId>

<ns1:commandIdentifier>OnDemandReadScalar</ns1:commandIdentifier>

<ns1:utilityDeviceIds>

<ns1:utilityDeviceIdentifierNumber>AM_ODR_SCALAR_01</ns1:utilityDeviceIdentifierNumber>

<ns1:utilityDeviceIdentifierNumber>AM_ODR_SCALAR_02</ns1:utilityDeviceIdentifierNumber>

<ns1:utilityDeviceIdentifierNumber>AM_ODR_SCALAR_03</ns1:utilityDeviceIdentifierNumber>

<ns1:utilityDeviceIdentifierNumber>AM_ODR_SCALAR_04</ns1:utilityDeviceIdentifierNumber>

</ns1:utilityDeviceIds>

<ns1:expirationDateTime></ns1:expirationDateTime>

<ns1:callbackURL></ns1:callbackURL>

</ns1:bulkRequest>

</soap:Body>

</soap:Envelope>

The following table describes the elements in the input arguments:

Element

Description

bulkRequest

Header element that contains a bulk request.

responseCreationMethod

Specifies the method in which responses are created for requests submitted from external systems. Valid values include:

•

One by One (D1ON)

•

Timed (D1TM)

•

Wait for All (D1WT)

timedResponseBeforeAllReceived

Specifies whether or not a response should be sent back to external system before all commands are received. Valid values are:

•

true

•

false

externalBulkRequestId

An ID given by the external system to represent the request.

externalRequesterId

The ID of the external system submitting the request. This must match the External System linked to the Service provider that represents the external system

commandIdentifier

Specifies the command to initiate for the listed devices. Valid values include:

•

DeviceStatusCheck

•

DeviceCommissioning

•

DeviceDecommissioning

•

EnableService

•

OnDemandReadInterval

•

OnDemandReadScalar

•

RemoteConnect

•

RemoteDisconnect

utilityDeviceIds

Element containing one or more utilityDeviceIdentifierNumber elements that specify individual devices for which the specified command is to be initiated.

utilityDeviceIdentifierNumber

The Device Identifier Number for the device for which the specified command is to be initiated.

This value should be based on the "AMI Device ID Type" specified on the Service Provider that represents the external system submitting the request.

expirationDateTime

The date and time after which commands that have not yet completed are discarded

callbackURL

The URL from the external system where information is sent if a fault occurs while processing commands. If empty, no fault information is sent.

Batch Processing

This chapter describes the base package batch processes provided with Oracle Utilities Service and Measurement Data Foundation.

Refer to the following documentation for more information about batch processing:

•

Oracle Utilities Smart Grid Gateway Batch Server Administration Guide

•

Oracle Utilities Application Framework Business Process Guide (Batch Jobs)

•

Oracle Utilities Application Framework Administration Guide (Defining Background Processes)

Service and Measurement Data Foundation Base Package Batch Controls

The table below lists the batch controls provided in the Service and Measurement Data Foundation base package.

Batch Control

Name / Description

D1-ACTVY

Activity Monitor

Invokes the generic Application Framework auto-transition batch process that can do automatic/scheduled transition for activities

D1-CCMTR

Communication Comp State Monitor Process

D1-CEWR

Completion Event with Retry Monitor

D1-CMCS

Create Measurement Cycle Schedule Routes

D1-COMM

Batch Control for Communications

D1-CPSR

Complete Pending Msrmt Cycle Schd Routes - DEPRECATED

D1-CRERR

Command Request Error - Retry

D1-CRWT

Command Request Wait - Monitor

D1-CSPSR

Create SP Msrmt Cycle Schedule Rte Records

D1-DVEVS

Device Event Seeder Monitor Process

D1-DVEVT

Device Event MO Periodic Monitor Process

D1-EXTSC

Usage/Event Extract Scheduler Monitor

D1-GNIMD

Generic IMD Monitor - IMD Seeder

D1-IBCOM

Inbound Communication Wait - Monitor

D1-ICERR

Inbound Communication Error - Retry

D1-ICOMM

Generic Inbound Communication Batch Control

D1-IMD

IMD Monitor - Physical Devices

Invokes monitoring rules associated with the current state of an initial measurement. All monitoring rules throughout the initial measurement's business object's inheritance chain are considered.

Batch parameters govern whether the processing is further restricted by batch code, business object, status, etc.

D1-IMDMC

IMD Monitor Unattached MCs

D1-INEVT

Install Event MO Periodic Monitor Process

Invokes monitoring rules associated with the current state of an install event. All monitoring rules throughout the install event's business object's inheritance chain are considered.

By default, the process periodically monitors install events whose current state is not associated with a batch code. Batch parameters govern whether the processing is further restricted by batch code, business object and status.

D1-MC

MC MO Periodic Monitor Process

Invokes monitoring rules associated with the current state of a measuring component. All monitoring rules throughout the measuring component's business object's inheritance chain are considered.

By default, the process periodically monitors measuring components whose current state is not associated with a batch code. Batch parameters govern whether the processing is further restricted by batch code, business object and status.

D1-MSRMT

Measurement - Derive Other Values

Initiates a reprocessing of Derive Other Values for Measurements. To do this, it moves the status of the Measurement from OK to REDERIVEVAL. The REDERIVEVAL status will have a monitor algorithm that will execute all "Derive Other Values" algorithms that have been attached to the business object's Plug-in spot.

Batch parameters are required and are used to select the specific business object as well as the starting date and ending date for the records to be processed.

D1-OBCOM

Outbound Communication Wait - Monitor

D1-OCERR

Outbound Communication Error - Retry

D1-OCOMM

Generic Outbound Communication Batch Control

D1-OCWT

Outbound Communication Wait - Monitor

D1-PMCS

DEPRECATED - Process Measurement Cycle Schedule

D1-PSACC

Payload Statistics Accumulation - Monitor

D1-PSPSR

Process SP / MC Schedule Route Records

D1-SMMTR

Smart Meter State Monitor Process

D1-SP

Service Point MO Periodic Monitor Process

Invokes monitoring rules associated with the current state of a service point. All monitoring rules throughout the service point's business object's inheritance chain are considered.

By default, the process periodically monitors service points whose current state is not associated with a batch code. Batch parameters govern whether the processing is further restricted by batch code, business object and status.

D1-SYNC

Data Sync MO Periodic Monitor Process

D1-TOUTR

Time of Use Map Data Generation Monitor

Invokes monitor algorithms for Time Of Use Map instances whose current state does not reference a monitor process.

D1-UT

Usage Transaction Monitor Process - NOT USED

D1-UTCD

Usage Transaction Calculate Defer Monitor - NOT USED

D1-UTCRN

Usage Transaction Correction Monitor

D1-UTID

Usage Transaction Issue Detected Monitor - NOT USED

D1-UTSED

Usage Transaction Seeder - Error - NOT USED

Synchronization Request Batch Controls

The table below lists the batch controls used by the Service and Measurement Data Foundation for data synchronization. "Initial Sync Request - Load Data <batch control>" batch controls load data (created new instances of business objects) for requests of the appropriate type (device, measuring component, etc,). "Initial Sync Request - Resolve Keys <batch control>" batch controls invoke a generic maintenance object transition process to invoke the "Resolve Keys - Initial Sync" algorithm for synchronization requests of the appropriate type.

Batch Control

Description

D1-CMSYN

Composite Sync Request

Transition Composite Sync Request BO instances in Pending state to the next state.

D1-SIIER

Initial Sync Request - Error

Transition Initial Inbound Sync Request BO instances in Error state to the next state.

D1-SILCN

Initial Sync Request - Load Data Contact

D1-SILDC

Initial Sync Request - Load Data DC

D1-SILDV

Initial Sync Request - Load Data Device

D1-SILIE

Initial Sync Request - Load Data IE

D1-SILMC

Initial Sync Request - Load Data MC

D1-SILSP

Initial Sync Request - Load Data SP

D1-SILUS

Initial Sync Request - Load Data US

D1-SIKCN

Initial Sync Request - Resolve Keys Contact

D1-SIKDC

Initial Sync Request - Resolve Keys DC

D1-SIKDC

Initial Sync Request - Resolve Keys Device

D1-SIKIE

Initial Sync Request - Resolve Keys IE

D1-SIKMC

Initial Sync Request - Resolve Keys MC

D1-SIKSP

Initial Sync Request - Resolve Keys SP

D1-SIKUS

Initial Sync Request - Resolve Keys US

D1-SIOER

Ongoing Sync Request -Error

Transition Ongoing Inbound Sync Request BO instances in Error state to the next state.

D1-SIOPE

Ongoing Sync Request - Pending

Transition Ongoing Inbound Sync Request BO instances in Pending state to the next state.

D1-SRSDE

Snyc Request Seeder - Error

Transition Sync Request Seeder BO instances in Error state to the next state.

D2-SIKUS

Initial Sync Request - Resolve Keys US

D2-SILUS

Initial Sync Request - Load Data US

Service and Measurement Data Foundation Batch Processing Guidelines

This section provides some guidelines around how to schedule batch processing for the batch controls used with Service and Measurement Data Foundation (including those used by Oracle Utilities Meter Data Management and Oracle Utilities Smart Grid Gateway). Note that there are no strict dependencies between batch controls, meaning there are no situations in which you must run a specific batch process before running any other. Dependencies are based on the way a utility wants to run their business.

Ongoing Processes

Throughout the course of the day, utilities will likely want to run jobs to bring measurement and event data in from their various metering / head-end systems and other external systems. To accompany this, they might want to run the following batch processes:

Ongoing Master Data Sync Processing

If the system is integrated with a customer information system such as Oracle Utilities Customer Care and Billing and synchronizing master data such as service points, install events, usage subscriptions, etc. on an ongoing basis, this data should be as up-to-date as possible when loading and processing data. This can include:

•

Processing composite sync requets that will create individual sync requests for multiple objects (D1-CMSYN)

•

"Cleaning out" any ongoing sync requests in error from previous runs (D1-SIOER) and those that have more severe issues and remain as sync request "seeders" (D1-SRSDE)

•

Processing sync records that are pending (D1-SIOPE), and again those in error (D1-SIOER).

Note: Processing records in error after processing the batch of "pending" ongoing sync requests is a recommended practice as it serves to clean up dependent sync requests that may have been picked up in an incorrect order. For example, attempting to process a Usage Subscription sync request referencing a Service Point before processing that service point’s sync request will put the usage subscription sync request in error. Running D1-SIOER will pick up that usage subscription sync request that had been left behind, and can process it successfully now that the service point it references has been synced in.

Ongoing master data sync could be part of a nightly schedule rather than running it throughout the day, depending on whether the attributes being synced impact VEE and/or usage processing. If nothing synced from a source system impacts VEE, then sync processing need not be run before VEE.

Command Processing

If using Oracle Utilities Smart Grid Gateway to process device commands, it’s important to keep communications flowing to and from smart meters to provide the most accurate picture of the state of a given meter. This would include:

•

Retrying inbound communications in error (D1-ICERR)

•

Retrying outbound communications in error (D1-OCERR)

•

Processing outbound communications waiting for a response (D1-OCWT) to see if they should be timed out.

•

Processing command request activities in error (D1-CRERR) and those that are waiting (D1-CRWT)

Note that base package business objects for communications and command activities are designed to trap any processing errors encountered and transition the object into an Error state. To deal with unexpected errors that can't be traped, which could leave communications / command activities in unmonitored states, implementations can choose to configure their own batch controls based on the delivered D1-ACTVY and D1-COMM batch controls, restricting records processed by business object or maintenance object as needed.

Initial Measurement Processing

For initial measurement processing, the following batch processes should be scheduled on a ongoing basis:

•

Processing initial measurements in the pending state (D1-IMD)

•

Processing initial measurementss in the exception state (D1-GNIMD)

In addition, processing initial measurement seeders (IMD Seeders) in error should be performed. This can be accomplished through creation of a custom batch control that references the following Java program used by the "Generic IMD Monitor" (D1-GNIMD):

com.splwg.base.domain.common.businessObject.batch.AutoTransitionBatchProcess

This custom batch process could be configured to restrict processing to the IMD Seeder business object (D1-IMDSeeder).

Event Processing

The base package is configured such that device events are processed immediately upon receipt, since they might need to be sent to some other application such as an outage system. This can be changed by configuring a monitor process on the device event business object to stop records in a specified state, and then use a batch process to process the events all at once. Beyond this type batch-oriented processing for events, other even processing could include:

•

Re-processing device event "seeders" in error (D1-DVEVS),

•

Picking up device events for processing if they've stopped in any state (D1-DVEVT).

If device events are configured to be held from being sent onto downstream applications, such as to prevent "flicker" outage events (an outage event and a restore event received in rapid succession) from being sent, device event monitoring (D1-DVEVT) should be set up to be run periodically to ensure timely transmission of events.

Daily/Nightly

In addition to the above ongoing processes, the following daily or nightly processes can also be scheduled.

Periodic Interval/Smart Meter Estimation

Periodic estimation is driven by monitoring devices via the "Smart Meter State Monitor Process" batch control (D1-SMMTR) which executes a monitor algorithm to execute the estimation algorithm on the measuring component business object, which in turn can be configured to create Estimated initial measurements.

Measurement Cycle Processing (Optional)

If using a billing system that doesn’t request for bill determinants and requires that bill determinants be pushed to it, the following processes can be used:

•

Creating meter read cycle schedule routes (D1-CMCS)

•

Creating SP / Measurement Cycle Schedule Routes (D1-CSPSR)

•

Processing SP / Measurement Cycle Schedule Routes (D1-PSPSR)

The above processes can also be used to drive the download of meter read cycle & route information for manually-read meters.

Periodic / Ad Hoc

In addition to the above ongoing and daily/nightly processes, the following periodic processes can be run on an as needed basis.

TOU Map Data Generation

TOU map data must be in place for all TOU maps used in usage calculations. Generation of this data is performed using the "Time of Use Map Data Generation Monitor" batch control (D1-TOUTR). This process can be peformed for long time periods, such as a year, generating data for all time-of-use maps for the entire following year, or it could be done more frequently, such as whenever schedules are updated via the TOU map templates.

Re-Derive Measurement Values

If certain data such as a factor value was found to be incorrect, derived measurement values might need to be re-calculated across all final measurements for a given date range. This can be performed using the "Measurement - Derive Other Values" batch control (D1-MSRMT). Given the possible volume of data impacted by this process, careful consideration should be given before performing this process.

Master Data Monitoring

The base package also provides batch processes intended to monitor service points (D1-SP), install events (D1-INEVT), and measuring components (D1-MC) on an ad-hoc basis if processing driven from the lifecycles of these objects is needed. Note that the base package contains no such processing.

Service and Measurement Data Foundation Batch Processing Guidelines

This section provides some guidelines around how to schedule batch processing for the batch controls used with Service and Measurement Data Foundation (including those used by Oracle Utilities Meter Data Management and Oracle Utilities Smart Grid Gateway). Note that there are no strict dependencies between batch controls, meaning there are no situations in which you must run a specific batch process before running any other. Dependencies are based on the way a utility wants to run their business.

Ongoing Processes

Throughout the course of the day, utilities will likely want to run jobs to bring measurement and event data in from their various metering / head-end systems and other external systems. To accompany this, they might want to run the following batch processes:

Ongoing Master Data Sync Processing

If the system is integrated with a customer information system such as Oracle Utilities Customer Care and Billing and synchronizing master data such as service points, install events, usage subscriptions, etc. on an ongoing basis, this data should be as up-to-date as possible when loading and processing data. This can include:

•

Processing composite sync requets that will create individual sync requests for multiple objects (D1-CMSYN)

•

"Cleaning out" any ongoing sync requests in error from previous runs (D1-SIOER) and those that have more severe issues and remain as sync request "seeders" (D1-SRSDE)

•

Processing sync records that are pending (D1-SIOPE), and again those in error (D1-SIOER).

Note: Processing records in error after processing the batch of "pending" ongoing sync requests is a recommended practice as it serves to clean up dependent sync requests that may have been picked up in an incorrect order. For example, attempting to process a Usage Subscription sync request referencing a Service Point before processing that service point’s sync request will put the usage subscription sync request in error. Running D1-SIOER will pick up that usage subscription sync request that had been left behind, and can process it successfully now that the service point it references has been synced in.

Ongoing master data sync could be part of a nightly schedule rather than running it throughout the day, depending on whether the attributes being synced impact VEE and/or usage processing. If nothing synced from a source system impacts VEE, then sync processing need not be run before VEE.

Command Processing

If using Oracle Utilities Smart Grid Gateway to process device commands, it’s important to keep communications flowing to and from smart meters to provide the most accurate picture of the state of a given meter. This would include:

•

Retrying inbound communications in error (D1-ICERR)

•

Retrying outbound communications in error (D1-OCERR)

•

Processing outbound communications waiting for a response (D1-OCWT) to see if they should be timed out.

•

Processing command request activities in error (D1-CRERR) and those that are waiting (D1-CRWT)

Note that base package business objects for communications and command activities are designed to trap any processing errors encountered and transition the object into an Error state. To deal with unexpected errors that can't be traped, which could leave communications / command activities in unmonitored states, implementations can choose to configure their own batch controls based on the delivered D1-ACTVY and D1-COMM batch controls, restricting records processed by business object or maintenance object as needed.

Initial Measurement Processing

For initial measurement processing, the following batch processes should be scheduled on a ongoing basis:

•

Processing initial measurements in the pending state (D1-IMD)

•

Processing initial measurementss in the exception state (D1-GNIMD)

In addition, processing initial measurement seeders (IMD Seeders) in error should be performed. This can be accomplished through creation of a custom batch control that references the following Java program used by the "Generic IMD Monitor" (D1-GNIMD):

com.splwg.base.domain.common.businessObject.batch.AutoTransitionBatchProcess

This custom batch process could be configured to restrict processing to the IMD Seeder business object (D1-IMDSeeder).

Event Processing

The base package is configured such that device events are processed immediately upon receipt, since they might need to be sent to some other application such as an outage system. This can be changed by configuring a monitor process on the device event business object to stop records in a specified state, and then use a batch process to process the events all at once. Beyond this type batch-oriented processing for events, other even processing could include:

•

Re-processing device event "seeders" in error (D1-DVEVS),

•

Picking up device events for processing if they've stopped in any state (D1-DVEVT).

If device events are configured to be held from being sent onto downstream applications, such as to prevent "flicker" outage events (an outage event and a restore event received in rapid succession) from being sent, device event monitoring (D1-DVEVT) should be set up to be run periodically to ensure timely transmission of events.

Daily/Nightly

In addition to the above ongoing processes, the following daily or nightly processes can also be scheduled.

Periodic Interval/Smart Meter Estimation

Periodic estimation is driven by monitoring devices via the "Smart Meter State Monitor Process" batch control (D1-SMMTR) which executes a monitor algorithm to execute the estimation algorithm on the measuring component business object, which in turn can be configured to create Estimated initial measurements.

Measurement Cycle Processing (Optional)

If using a billing system that doesn’t request for bill determinants and requires that bill determinants be pushed to it, the following processes can be used:

•

Creating meter read cycle schedule routes (D1-CMCS)

•

Creating SP / Measurement Cycle Schedule Routes (D1-CSPSR)

•

Processing SP / Measurement Cycle Schedule Routes (D1-PSPSR)

The above processes can also be used to drive the download of meter read cycle & route information for manually-read meters.

Periodic / Ad Hoc

In addition to the above ongoing and daily/nightly processes, the following periodic processes can be run on an as needed basis.

TOU Map Data Generation

TOU map data must be in place for all TOU maps used in usage calculations. Generation of this data is performed using the "Time of Use Map Data Generation Monitor" batch control (D1-TOUTR). This process can be peformed for long time periods, such as a year, generating data for all time-of-use maps for the entire following year, or it could be done more frequently, such as whenever schedules are updated via the TOU map templates.

Re-Derive Measurement Values

If certain data such as a factor value was found to be incorrect, derived measurement values might need to be re-calculated across all final measurements for a given date range. This can be performed using the "Measurement - Derive Other Values" batch control (D1-MSRMT). Given the possible volume of data impacted by this process, careful consideration should be given before performing this process.

Master Data Monitoring

The base package also provides batch processes intended to monitor service points (D1-SP), install events (D1-INEVT), and measuring components (D1-MC) on an ad-hoc basis if processing driven from the lifecycles of these objects is needed. Note that the base package contains no such processing.

Service and Measurement Data Foundation Batch Processing Guidelines

This section provides some guidelines around how to schedule batch processing for the batch controls used with Service and Measurement Data Foundation (including those used by Oracle Utilities Meter Data Management and Oracle Utilities Smart Grid Gateway). Note that there are no strict dependencies between batch controls, meaning there are no situations in which you must run a specific batch process before running any other. Dependencies are based on the way a utility wants to run their business.

Ongoing Processes

Throughout the course of the day, utilities will likely want to run jobs to bring measurement and event data in from their various metering / head-end systems and other external systems. To accompany this, they might want to run the following batch processes:

Ongoing Master Data Sync Processing

If the system is integrated with a customer information system such as Oracle Utilities Customer Care and Billing and synchronizing master data such as service points, install events, usage subscriptions, etc. on an ongoing basis, this data should be as up-to-date as possible when loading and processing data. This can include:

•

Processing composite sync requets that will create individual sync requests for multiple objects (D1-CMSYN)

•

"Cleaning out" any ongoing sync requests in error from previous runs (D1-SIOER) and those that have more severe issues and remain as sync request "seeders" (D1-SRSDE)

•

Processing sync records that are pending (D1-SIOPE), and again those in error (D1-SIOER).

Note: Processing records in error after processing the batch of "pending" ongoing sync requests is a recommended practice as it serves to clean up dependent sync requests that may have been picked up in an incorrect order. For example, attempting to process a Usage Subscription sync request referencing a Service Point before processing that service point’s sync request will put the usage subscription sync request in error. Running D1-SIOER will pick up that usage subscription sync request that had been left behind, and can process it successfully now that the service point it references has been synced in.

Ongoing master data sync could be part of a nightly schedule rather than running it throughout the day, depending on whether the attributes being synced impact VEE and/or usage processing. If nothing synced from a source system impacts VEE, then sync processing need not be run before VEE.

Command Processing

If using Oracle Utilities Smart Grid Gateway to process device commands, it’s important to keep communications flowing to and from smart meters to provide the most accurate picture of the state of a given meter. This would include:

•

Retrying inbound communications in error (D1-ICERR)

•

Retrying outbound communications in error (D1-OCERR)

•

Processing outbound communications waiting for a response (D1-OCWT) to see if they should be timed out.

•

Processing command request activities in error (D1-CRERR) and those that are waiting (D1-CRWT)

Note that base package business objects for communications and command activities are designed to trap any processing errors encountered and transition the object into an Error state. To deal with unexpected errors that can't be traped, which could leave communications / command activities in unmonitored states, implementations can choose to configure their own batch controls based on the delivered D1-ACTVY and D1-COMM batch controls, restricting records processed by business object or maintenance object as needed.

Initial Measurement Processing

For initial measurement processing, the following batch processes should be scheduled on a ongoing basis:

•

Processing initial measurements in the pending state (D1-IMD)

•

Processing initial measurementss in the exception state (D1-GNIMD)

In addition, processing initial measurement seeders (IMD Seeders) in error should be performed. This can be accomplished through creation of a custom batch control that references the following Java program used by the "Generic IMD Monitor" (D1-GNIMD):

com.splwg.base.domain.common.businessObject.batch.AutoTransitionBatchProcess

This custom batch process could be configured to restrict processing to the IMD Seeder business object (D1-IMDSeeder).

Event Processing

The base package is configured such that device events are processed immediately upon receipt, since they might need to be sent to some other application such as an outage system. This can be changed by configuring a monitor process on the device event business object to stop records in a specified state, and then use a batch process to process the events all at once. Beyond this type batch-oriented processing for events, other even processing could include:

•

Re-processing device event "seeders" in error (D1-DVEVS),

•

Picking up device events for processing if they've stopped in any state (D1-DVEVT).

If device events are configured to be held from being sent onto downstream applications, such as to prevent "flicker" outage events (an outage event and a restore event received in rapid succession) from being sent, device event monitoring (D1-DVEVT) should be set up to be run periodically to ensure timely transmission of events.

Daily/Nightly

In addition to the above ongoing processes, the following daily or nightly processes can also be scheduled.

Periodic Interval/Smart Meter Estimation

Periodic estimation is driven by monitoring devices via the "Smart Meter State Monitor Process" batch control (D1-SMMTR) which executes a monitor algorithm to execute the estimation algorithm on the measuring component business object, which in turn can be configured to create Estimated initial measurements.

Measurement Cycle Processing (Optional)

If using a billing system that doesn’t request for bill determinants and requires that bill determinants be pushed to it, the following processes can be used:

•

Creating meter read cycle schedule routes (D1-CMCS)

•

Creating SP / Measurement Cycle Schedule Routes (D1-CSPSR)

•

Processing SP / Measurement Cycle Schedule Routes (D1-PSPSR)

The above processes can also be used to drive the download of meter read cycle & route information for manually-read meters.

Periodic / Ad Hoc

In addition to the above ongoing and daily/nightly processes, the following periodic processes can be run on an as needed basis.

TOU Map Data Generation

TOU map data must be in place for all TOU maps used in usage calculations. Generation of this data is performed using the "Time of Use Map Data Generation Monitor" batch control (D1-TOUTR). This process can be peformed for long time periods, such as a year, generating data for all time-of-use maps for the entire following year, or it could be done more frequently, such as whenever schedules are updated via the TOU map templates.

Re-Derive Measurement Values

If certain data such as a factor value was found to be incorrect, derived measurement values might need to be re-calculated across all final measurements for a given date range. This can be performed using the "Measurement - Derive Other Values" batch control (D1-MSRMT). Given the possible volume of data impacted by this process, careful consideration should be given before performing this process.

Master Data Monitoring

The base package also provides batch processes intended to monitor service points (D1-SP), install events (D1-INEVT), and measuring components (D1-MC) on an ad-hoc basis if processing driven from the lifecycles of these objects is needed. Note that the base package contains no such processing.

Service and Measurement Data Foundation Batch Processing Guidelines

This section provides some guidelines around how to schedule batch processing for the batch controls used with Service and Measurement Data Foundation (including those used by Oracle Utilities Meter Data Management and Oracle Utilities Smart Grid Gateway). Note that there are no strict dependencies between batch controls, meaning there are no situations in which you must run a specific batch process before running any other. Dependencies are based on the way a utility wants to run their business.

Ongoing Processes

Throughout the course of the day, utilities will likely want to run jobs to bring measurement and event data in from their various metering / head-end systems and other external systems. To accompany this, they might want to run the following batch processes:

Ongoing Master Data Sync Processing

If the system is integrated with a customer information system such as Oracle Utilities Customer Care and Billing and synchronizing master data such as service points, install events, usage subscriptions, etc. on an ongoing basis, this data should be as up-to-date as possible when loading and processing data. This can include:

•

Processing composite sync requets that will create individual sync requests for multiple objects (D1-CMSYN)

•

"Cleaning out" any ongoing sync requests in error from previous runs (D1-SIOER) and those that have more severe issues and remain as sync request "seeders" (D1-SRSDE)

•

Processing sync records that are pending (D1-SIOPE), and again those in error (D1-SIOER).

Note: Processing records in error after processing the batch of "pending" ongoing sync requests is a recommended practice as it serves to clean up dependent sync requests that may have been picked up in an incorrect order. For example, attempting to process a Usage Subscription sync request referencing a Service Point before processing that service point’s sync request will put the usage subscription sync request in error. Running D1-SIOER will pick up that usage subscription sync request that had been left behind, and can process it successfully now that the service point it references has been synced in.

Ongoing master data sync could be part of a nightly schedule rather than running it throughout the day, depending on whether the attributes being synced impact VEE and/or usage processing. If nothing synced from a source system impacts VEE, then sync processing need not be run before VEE.

Command Processing

If using Oracle Utilities Smart Grid Gateway to process device commands, it’s important to keep communications flowing to and from smart meters to provide the most accurate picture of the state of a given meter. This would include:

•

Retrying inbound communications in error (D1-ICERR)

•

Retrying outbound communications in error (D1-OCERR)

•

Processing outbound communications waiting for a response (D1-OCWT) to see if they should be timed out.

•

Processing command request activities in error (D1-CRERR) and those that are waiting (D1-CRWT)

Note that base package business objects for communications and command activities are designed to trap any processing errors encountered and transition the object into an Error state. To deal with unexpected errors that can't be traped, which could leave communications / command activities in unmonitored states, implementations can choose to configure their own batch controls based on the delivered D1-ACTVY and D1-COMM batch controls, restricting records processed by business object or maintenance object as needed.

Initial Measurement Processing

For initial measurement processing, the following batch processes should be scheduled on a ongoing basis:

•

Processing initial measurements in the pending state (D1-IMD)

•

Processing initial measurementss in the exception state (D1-GNIMD)

In addition, processing initial measurement seeders (IMD Seeders) in error should be performed. This can be accomplished through creation of a custom batch control that references the following Java program used by the "Generic IMD Monitor" (D1-GNIMD):

com.splwg.base.domain.common.businessObject.batch.AutoTransitionBatchProcess

This custom batch process could be configured to restrict processing to the IMD Seeder business object (D1-IMDSeeder).

Event Processing

The base package is configured such that device events are processed immediately upon receipt, since they might need to be sent to some other application such as an outage system. This can be changed by configuring a monitor process on the device event business object to stop records in a specified state, and then use a batch process to process the events all at once. Beyond this type batch-oriented processing for events, other even processing could include:

•

Re-processing device event "seeders" in error (D1-DVEVS),

•

Picking up device events for processing if they've stopped in any state (D1-DVEVT).

If device events are configured to be held from being sent onto downstream applications, such as to prevent "flicker" outage events (an outage event and a restore event received in rapid succession) from being sent, device event monitoring (D1-DVEVT) should be set up to be run periodically to ensure timely transmission of events.

Daily/Nightly

In addition to the above ongoing processes, the following daily or nightly processes can also be scheduled.

Periodic Interval/Smart Meter Estimation

Periodic estimation is driven by monitoring devices via the "Smart Meter State Monitor Process" batch control (D1-SMMTR) which executes a monitor algorithm to execute the estimation algorithm on the measuring component business object, which in turn can be configured to create Estimated initial measurements.

Measurement Cycle Processing (Optional)

If using a billing system that doesn’t request for bill determinants and requires that bill determinants be pushed to it, the following processes can be used:

•

Creating meter read cycle schedule routes (D1-CMCS)

•

Creating SP / Measurement Cycle Schedule Routes (D1-CSPSR)

•

Processing SP / Measurement Cycle Schedule Routes (D1-PSPSR)

The above processes can also be used to drive the download of meter read cycle & route information for manually-read meters.

Periodic / Ad Hoc

In addition to the above ongoing and daily/nightly processes, the following periodic processes can be run on an as needed basis.

TOU Map Data Generation

TOU map data must be in place for all TOU maps used in usage calculations. Generation of this data is performed using the "Time of Use Map Data Generation Monitor" batch control (D1-TOUTR). This process can be peformed for long time periods, such as a year, generating data for all time-of-use maps for the entire following year, or it could be done more frequently, such as whenever schedules are updated via the TOU map templates.

Re-Derive Measurement Values

If certain data such as a factor value was found to be incorrect, derived measurement values might need to be re-calculated across all final measurements for a given date range. This can be performed using the "Measurement - Derive Other Values" batch control (D1-MSRMT). Given the possible volume of data impacted by this process, careful consideration should be given before performing this process.

Master Data Monitoring

The base package also provides batch processes intended to monitor service points (D1-SP), install events (D1-INEVT), and measuring components (D1-MC) on an ad-hoc basis if processing driven from the lifecycles of these objects is needed. Note that the base package contains no such processing.

Integrating Oracle Utilities Smart Grid Gateway with Other Systems

This chapter provides an overview of how Oracle Utilities Smart Gird Gateway can be integrated with other systems, including:

•

Understanding Communications Processing

•

Invoking Meter Commands From an External System

•

Creating Custom Smart Grid Gateway Adapters

•

Initial Measurement and Device Event XML Formats

•

Usage and Event Import - Message Driven Bean Configuration

Understanding Communications Processing

This section describes the manner in which Oracle Utilities Smart Grid Gateway communicates with head-end systems, including:

•

One-Way Communications: Import of Usage and Events

•

Two-Way Communications: Meter Commands

One-Way Communications: Import of Usage and Events

Importing of usage readings and device events is supported through one-way communications with a head-end system: the head-end system sends a payload of usage readings or events, and Oracle Utilities Smart Grid Gateway picks up the payload and imports the readings and/or events into the system.

The table below provides an overview of the process that takes place when usage or device events are received. For each step in the process, the table below provides a brief description of the processing that takes place, and lists the specific Service and Measurement Data Foundation objects used in processing that step or operation.

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

Step

Process

Service and Measurement Data Foundation Objects

1.

The head-end system sends a payload of usage readings or device events to middleware components. The device event paylaod contains both standard and paried device events.

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus. (OSB) as the middleware components for import of usage readings and device events,

2.

The middleware parses the payload into individual usage readings or device events and then transforms each from the format used by the head-end system into the SGG format.

3.

The middleware then invokes an XAI Inbound Service for each reading or device event.

For usage readings, the middleware invokes the Initial Load IMD inbound service. This service is mapped to the IMD Seeder business object.

For device events, the middleware invokes he Device Event Seeder inbound service. This service is mapped to the Device Event Seeder business object.

Usage Reading XAI Inbound Service: D1-InitialLoadIMD (D107437309)

Device Event XAI Inbound Service: D1-DeviceEventSeeder (D103879193)

4.

The IMD Seeder business object determines the type of initial measurement business object to create for each reading based on the processing method defined for the "Initial Measurement Creation" processing role on the head-end system service provider.

Different head-end systems may use different names for units of measure (UOMs). The IMD Seeder business object maps vendor-specific UOMs to "standard" UOMs based on the processing method defined for the "UOM Mapping" processing role on the head-end system service provider.

The Device Event Seeder business object determines the type of device event business object to create based on the Device Event Mapping business object (extendable lookup) defined for the head-end system service provider.

Different head-end systems may use different names for the same type of event. This process maps device event names sent by the head-end system to standard device event names.

IMD Seeder Processing Method: D1-HowToCreateMCInformation (How to Create MD Related Information)

UOM MappingBO: D1-HowToProcessDeviceInfo (How to Process Device Related Information)

Device Event Seeder Processing Method: D1-HowToProcessDeviceInfo (How to Process Device Related Information)

Device Event Mapping BO: D1-DeviceEventMappingLookup

5.

An instance of the appropriate initial measurement data business object is created in the system for each usage reading received.

An instance of the appropriate device event business object is created in the system for each device event received.

For paired events, the first event business objects may create activities to represent the event.

Initial Measurement Data BOs:

•

D1-InitialLoadIMDInterval

•

D1-InitialLoadIMDScalar

Standard Device Event BO: D1-StandardDeviceEvent

Paired (First) Device Event BO: D1-PairedEventFirstDeviceEvent (Device Event - Paired Event (First)

Paired (Last) Device Event BO: D1-PairedEventLastDeviceEvent (Device Event - Paired Event (Last)

6.

Device Events Only:

If there are systems that subscribe to device events (defined in a processing method for the system service provider), the device event is sent to those systems.

Sending device event information is triggered by an Enter algorithm on the "Processed" Status of the device event business object’s lifecycle.

Note: Sending device event information may involve configuration of XAI senders, outbound message types, and external systems. Refer to the Oracle Utilities Application Framework for more information about using XAI.

Procesing Method: D1-HowToProcDveEvtsInformation (How to Process Device Event Related Info)

Refer to the following documentation for more details concerning the specific configurations of Oracle Service Bus and the specific business objects used by Oracle Utilities Smart Gird Gateway adapters for importing usage reading and device events:

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Echelon Configuration Guide

•

Oracle Utilities Smart Grid Gateway MV90 Adapter for Itron Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Sensus Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Silver Springs Network Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter Development Kit Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Itron OpenWay Configuration Guide

Two-Way Communications: Meter Commands

Issuing meters commands and receiving a response from the head-end system is supported through two-way communications with a head-end system: Oracle Utilities Smart Grid Gateway sends a message for the command, the head-end system receives and performs the command, and then sends an acknowledgement back to Oracle Utilities Smart Grid Gateway.

The table below provides an overview of the communication process that takes place when a command is initiated for a device. For each step in the process, the table below provides a brief description of the processing that takes place, and lists the specific objects used by the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr. Refer to the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr Configuration Guide for more details about the configuration objects used by this adapter.

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

Step

Process

Landis+Gyr Adapter Objects

1.

A user initiates a remote connect command for a device.

A remote connect activity business object is instantiated for the command.

Activity BO: D1-RemoteConnect (Remote Connect)

2.

The remote connect command activity business object creates an outbound communication.

The specific type of outbound communication business object created is determined by the head-end system service provider (based on the processing role defined in the Enter algorithm of the "Awaiting Response" status of the outbound communication business object’s lifecycle).

Outbound Comunication BO: D3-InitiateConnectDisconnect (Initiate Connect Disconnect)

3.

The outbound communication creates an outbound message.

The specific type of outbound message created is determined by the head-end system service provider. (based on the processing role defined in the Enter algorithm of the "Awaiting Response" status of the outbound communication business object’s lifecycle).

Outbound Message Type: D3-CONNECT (Connect Device)

4.

The outbound message is sent to middleware components via an External System and XAI Sender.

Oracle Utilities Smart Grid Gateway adapters use Oracle Business Process Execution Language (BPEL) as the middleware components for communication with head-end systems.

External System: Landis+Gyr Head End System

XAI Sender: D3-Connect (Connect Device)

5.

The middleware converts the outbound message from SGG format into the format used by the head-end system, and sends the message to the head-end system.

6.

When the head-end system sends a response, the middlware receives the response message from the head-end system, and converts it from the format used by the head-end system to SGG format and invokes an XAI Inbound Service.

XAI Inbound Service: D3-ConDisconStChgNotification (D361040925)

7.

The XAI Inbound Service picks up the message, and creates a corresponding inbound communication.

The specific type of inbound communication business object created is determined by the XAI Inbound Service.

XAI Inbound Service: D3-ConDisconStChgNotification (D361040925)

Inbound Communication BO: D3-ConnectDisconStateChgNtf (Connect Disconnect State Changed Notification (Multispeak))

8.

The inbound communication identifies the parent outbound communication.

Outbound Comunication BO: D3-InitiateConnectDisconnect (Initiate Connect Disconnect)

9.

The inbound communication creates a completion event to update the status of the device to indicate it has been connected.

The specific type of completion event business object created is specified in an Enter algorithm on the "Create Completion Event" Status of the inbound communication business object’s lifecycle.

Completion Event BO: D1-ConnectDevice (Connect Device)

Algorithm: D3-CCE (Create Completion Event)

10.

The inbound communication updates the outbound communication.

This update is performed by an Enter algorithm on the "Completed" Status of the inbound communication business object’s lifecycle.

Outbound Comunication BO: D3-InitiateConnectDisconnect (Initiate Connect Disconnect)

11.

The outbound communication updates the "Connect/Disconnect Completion Flag" and the original activity business object.

This update is performed by an Enter algorithm on the "Completed" Status of the outbound communication business object’s lifecycle.

Outbound Comunication BO: D3-InitiateConnectDisconnect (Initiate Connect Disconnect)

Refer to the following documentation for more details concerning the specific configurations of Oracle Business Process Execution and the specific business objects used by Oracle Utilities Smart Gird Gateway adapters for supporting meter commands via two-way communication:

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Echelon Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Sensus Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Silver Springs Network Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter Development Kit Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Itron OpenWay Configuration Guide

Invoking Meter Commands From an External System

This section provides an overview of how to issue or invoke commands through Oracle Utilities Smart Grid Gateway from an external system. This is useful if implementing Oracle Utilities Smart Grid Gateway alongside external systems for which no productized integration is available, such as an outage system or customer information system.

This section includes:

•

Defining External System as a Service Provider

•

Exposing Command Activity Business Objects

•

Sending Command Responses to the External System

•

Configuring A Middleware Communication Layer

Defining External System as a Service Provider

The first step in enabling the issuing of commands through Oracle Utilities Smart Grid Gateway from an external system is to define the external system as a service provider. Several processes within Oracle Utilities Smart Grid Gateway use the service provider and its associated processing methods to determine how to process specific types of operations.

Service Providers are defined by the following:

•

Service Provider Business Object : The business object used to create the service provider. For external systems, this should be "External Application (D1-ExternalApplication)."

•

Service Provider : A code that designates the external system

•

Description : A description of the external system

•

External Reference ID : A reference ID for the external system

•

External System : A related external system (if applicable)

•

Our Name/ID in Their System : The name of Oracle Utilities Smart Grid Gateway as defined in the external system

•

Utility Device ID Type : The type of ID used by the external system to identify devices (badge number, external ID, internal meter number, serial number, or pallet number)

•

Utility Measuring Component ID Type : The type of ID used by the external system to identify measuring components ( channel ID or external ID)

Refer to the Oracle Utilities Service and Measurement Data Foundation user documentation for more information about creating service providers.

The table below contains an example service provider.

Attribute/Field

Value

Service Provider Business Object

External Application (D1-ExternalApplication)

Service Provider

CM_OUTAGE_SYSTEM

Description

Outage System

External Reference ID

12345

External System

N/A

Our Name/ID in Their System

OUSGG

Utility Device ID Type

Serial Number

Utility Measuring Component ID Type

Channel ID

Processing Methods

You must also define a number of processing methods for the service provider. These designate the method by which command (activity) related information is sent to the external system.

In this case, you want to define processing methods that designate how outbound messages related to commands (activities) are sent. The table below outlines the processing roles and methods that can be used for this.

Processing Role

Processing Method

Response - Received (D1RR)

How to Send Activity Related Outbound Messages (D1-HowToSendActivityResponses)

Response - Success (D1SR)

How to Send Activity Related Outbound Messages (D1-HowToSendActivityResponses)

Response - Failure (D1FR)

How to Send Activity Related Outbound Messages (D1-HowToSendActivityResponses)

For each of the above processing methods, you would define the outbound message type, or message category and message number to use when sending messages. The type of message to send can be a default type, or can be specified by activity (command) type.

Defining External System as a Service Provider

The first step in enabling the issuing of commands through Oracle Utilities Smart Grid Gateway from an external system is to define the external system as a service provider. Several processes within Oracle Utilities Smart Grid Gateway use the service provider and its associated processing methods to determine how to process specific types of operations.

Service Providers are defined by the following:

•

Service Provider Business Object : The business object used to create the service provider. For external systems, this should be "External Application (D1-ExternalApplication)."

•

Service Provider : A code that designates the external system

•

Description : A description of the external system

•

External Reference ID : A reference ID for the external system

•

External System : A related external system (if applicable)

•

Our Name/ID in Their System : The name of Oracle Utilities Smart Grid Gateway as defined in the external system

•

Utility Device ID Type : The type of ID used by the external system to identify devices (badge number, external ID, internal meter number, serial number, or pallet number)

•

Utility Measuring Component ID Type : The type of ID used by the external system to identify measuring components ( channel ID or external ID)

Refer to the Oracle Utilities Service and Measurement Data Foundation user documentation for more information about creating service providers.

The table below contains an example service provider.

Attribute/Field

Value

Service Provider Business Object

External Application (D1-ExternalApplication)

Service Provider

CM_OUTAGE_SYSTEM

Description

Outage System

External Reference ID

12345

External System

N/A

Our Name/ID in Their System

OUSGG

Utility Device ID Type

Serial Number

Utility Measuring Component ID Type

Channel ID

Processing Methods

You must also define a number of processing methods for the service provider. These designate the method by which command (activity) related information is sent to the external system.

In this case, you want to define processing methods that designate how outbound messages related to commands (activities) are sent. The table below outlines the processing roles and methods that can be used for this.

Processing Role

Processing Method

Response - Received (D1RR)

How to Send Activity Related Outbound Messages (D1-HowToSendActivityResponses)

Response - Success (D1SR)

How to Send Activity Related Outbound Messages (D1-HowToSendActivityResponses)

Response - Failure (D1FR)

How to Send Activity Related Outbound Messages (D1-HowToSendActivityResponses)

For each of the above processing methods, you would define the outbound message type, or message category and message number to use when sending messages. The type of message to send can be a default type, or can be specified by activity (command) type.

Exposing Command Activity Business Objects

The next step in enabling the issuing of commands through Oracle Utilities Smart Grid Gateway from an external system is to expose the activity business objects for the commands you wish to invoke as web services. This is done by creating an XAI Inbound Service for each command.

XAI Inbound Services are defined by the following:

•

XAI Inbound Service Name : A code for the inbound service.

•

Adapter : The type of adapter used by the inbound service. This should be "BusinessAdapter (Business Adapter)".

•

Schema Type : The type of object to be invoked via the inbound service (business object, business service, or service script). This should be Business Object.

•

Schema Name : The activity business object to invoke for the command

•

Description : A description of the inbound service.

When you create an XAI Inbound Service, the system creates the Web Service Definition Language (WSDL) schema for the service. This can be used by the external system to invoke the web services associated with each command.

The table below lists a set of sample XAI Inbound Services that could be created to support the commands supported through Oracle Utilities Smart Grid Gateway.

XAI Inbound Service

Schema Name

CM-DeviceCommissionService

D1-DeviceCommission (Device Commissioning)

CM-DeviceDecommissionService

D1-DeviceDecommission (Device Decommissioning)

CM-DeviceStatusCheckService

D1-DeviceStatusCheck (Device Status Check)

CM-OnDemandReadIntervalService

D1-OnDemandReadInterval (On-Demand Read Interval)

CM-OnDemandReadScalarService

D1-OnDemandReadScalar (On-Demand Read Scalar)

CM-RemoteConnectService

D1-RemoteConnect (Remote Connect)

CM-RemoteDisconnectService

D1-RemoteDisconnect (Remote Disconnect)

Refer to the Oracle Utilities Application Framework documentation for more information about XAI Inbound Services.

Sending Command Responses to the External System

The next step in enabling the issuing of commands through Oracle Utilities Smart Grid Gateway from an external system is to set up the configuration necessary to send outbound messages from Oracle Utilities Smart Grid Gateway to the external system. This includes configuring the following:

•

Outbound Message Types

•

XAI Senders

•

External Systems

Outbound Message Types

A outbound message type must also be created for each type of message to be sent to an external system, based on the types of messages the system is designed to accept. To continue the example above, you might create the following outbound message types:

Command

Outbound Message Type

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read Interval

On-Demand Read Interval

On-Demand Read Scalar

On-Demand Read Scalar

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about outbound message types.

XAI Senders

You must also create an XAI Sender for each type of message to be sent to an external system. XAI senders define the details of how messages are sent to an external system. The set of XAI senders you need to create is based on the types of messages the system is designed to accept. To continue the example above, you might create the following XAI senders:

Command

XAI Sender

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read

On-Demand Read

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about XAI senders.

External Systems

You must also create an External System for each external system to which Oracle Utilities Smart Grid Gateway will send messages. Each external system defines a set of outbound message types that will be sent to that system. Each external system outbound message type also specifies the following:

•

The processing method used to send the message (Batch, XAI, or Real-time)

•

The corresponding XAI senders

•

Batch Control (if Processing Method is set to Batch)

•

Message XSL, W3C Schema, and Response XSL (as applicable)

To continue the example above, you might create the following external system:

Head-End System

Outbound Message Type

Processing Method

XAI Sender

Message XSL /Response XSL

Commission Device

Real-time

Commission Device

OS-Request.xsl /

OS-Response.xsl

Decommission Device

Real-time

Decommission Device

OS-Request.xsl /

OS-Response.xsl

Device Status Check

Real-time

Device Status Check

OS-Request.xsl /

OS-Response.xsl

On-Demand Read

Real-time

On-Demand Read

OS-Request.xsl /

OS-Response.xsl

Remote Connect

Real-time

Connect Device

OS-Request.xsl /

OS-Response.xsl

Remote Disconnect

Real-time

Disconnect Device

OS-Request.xsl /

OS-Response.xsl

Refer to the Oracle Utilities Application Framework documentation for more information about external systems.

Sending Command Responses to the External System

The next step in enabling the issuing of commands through Oracle Utilities Smart Grid Gateway from an external system is to set up the configuration necessary to send outbound messages from Oracle Utilities Smart Grid Gateway to the external system. This includes configuring the following:

•

Outbound Message Types

•

XAI Senders

•

External Systems

Outbound Message Types

A outbound message type must also be created for each type of message to be sent to an external system, based on the types of messages the system is designed to accept. To continue the example above, you might create the following outbound message types:

Command

Outbound Message Type

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read Interval

On-Demand Read Interval

On-Demand Read Scalar

On-Demand Read Scalar

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about outbound message types.

XAI Senders

You must also create an XAI Sender for each type of message to be sent to an external system. XAI senders define the details of how messages are sent to an external system. The set of XAI senders you need to create is based on the types of messages the system is designed to accept. To continue the example above, you might create the following XAI senders:

Command

XAI Sender

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read

On-Demand Read

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about XAI senders.

External Systems

You must also create an External System for each external system to which Oracle Utilities Smart Grid Gateway will send messages. Each external system defines a set of outbound message types that will be sent to that system. Each external system outbound message type also specifies the following:

•

The processing method used to send the message (Batch, XAI, or Real-time)

•

The corresponding XAI senders

•

Batch Control (if Processing Method is set to Batch)

•

Message XSL, W3C Schema, and Response XSL (as applicable)

To continue the example above, you might create the following external system:

Head-End System

Outbound Message Type

Processing Method

XAI Sender

Message XSL /Response XSL

Commission Device

Real-time

Commission Device

OS-Request.xsl /

OS-Response.xsl

Decommission Device

Real-time

Decommission Device

OS-Request.xsl /

OS-Response.xsl

Device Status Check

Real-time

Device Status Check

OS-Request.xsl /

OS-Response.xsl

On-Demand Read

Real-time

On-Demand Read

OS-Request.xsl /

OS-Response.xsl

Remote Connect

Real-time

Connect Device

OS-Request.xsl /

OS-Response.xsl

Remote Disconnect

Real-time

Disconnect Device

OS-Request.xsl /

OS-Response.xsl

Refer to the Oracle Utilities Application Framework documentation for more information about external systems.

Sending Command Responses to the External System

The next step in enabling the issuing of commands through Oracle Utilities Smart Grid Gateway from an external system is to set up the configuration necessary to send outbound messages from Oracle Utilities Smart Grid Gateway to the external system. This includes configuring the following:

•

Outbound Message Types

•

XAI Senders

•

External Systems

Outbound Message Types

A outbound message type must also be created for each type of message to be sent to an external system, based on the types of messages the system is designed to accept. To continue the example above, you might create the following outbound message types:

Command

Outbound Message Type

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read Interval

On-Demand Read Interval

On-Demand Read Scalar

On-Demand Read Scalar

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about outbound message types.

XAI Senders

You must also create an XAI Sender for each type of message to be sent to an external system. XAI senders define the details of how messages are sent to an external system. The set of XAI senders you need to create is based on the types of messages the system is designed to accept. To continue the example above, you might create the following XAI senders:

Command

XAI Sender

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read

On-Demand Read

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about XAI senders.

External Systems

You must also create an External System for each external system to which Oracle Utilities Smart Grid Gateway will send messages. Each external system defines a set of outbound message types that will be sent to that system. Each external system outbound message type also specifies the following:

•

The processing method used to send the message (Batch, XAI, or Real-time)

•

The corresponding XAI senders

•

Batch Control (if Processing Method is set to Batch)

•

Message XSL, W3C Schema, and Response XSL (as applicable)

To continue the example above, you might create the following external system:

Head-End System

Outbound Message Type

Processing Method

XAI Sender

Message XSL /Response XSL

Commission Device

Real-time

Commission Device

OS-Request.xsl /

OS-Response.xsl

Decommission Device

Real-time

Decommission Device

OS-Request.xsl /

OS-Response.xsl

Device Status Check

Real-time

Device Status Check

OS-Request.xsl /

OS-Response.xsl

On-Demand Read

Real-time

On-Demand Read

OS-Request.xsl /

OS-Response.xsl

Remote Connect

Real-time

Connect Device

OS-Request.xsl /

OS-Response.xsl

Remote Disconnect

Real-time

Disconnect Device

OS-Request.xsl /

OS-Response.xsl

Refer to the Oracle Utilities Application Framework documentation for more information about external systems.

Sending Command Responses to the External System

The next step in enabling the issuing of commands through Oracle Utilities Smart Grid Gateway from an external system is to set up the configuration necessary to send outbound messages from Oracle Utilities Smart Grid Gateway to the external system. This includes configuring the following:

•

Outbound Message Types

•

XAI Senders

•

External Systems

Outbound Message Types

A outbound message type must also be created for each type of message to be sent to an external system, based on the types of messages the system is designed to accept. To continue the example above, you might create the following outbound message types:

Command

Outbound Message Type

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read Interval

On-Demand Read Interval

On-Demand Read Scalar

On-Demand Read Scalar

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about outbound message types.

XAI Senders

You must also create an XAI Sender for each type of message to be sent to an external system. XAI senders define the details of how messages are sent to an external system. The set of XAI senders you need to create is based on the types of messages the system is designed to accept. To continue the example above, you might create the following XAI senders:

Command

XAI Sender

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read

On-Demand Read

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about XAI senders.

External Systems

You must also create an External System for each external system to which Oracle Utilities Smart Grid Gateway will send messages. Each external system defines a set of outbound message types that will be sent to that system. Each external system outbound message type also specifies the following:

•

The processing method used to send the message (Batch, XAI, or Real-time)

•

The corresponding XAI senders

•

Batch Control (if Processing Method is set to Batch)

•

Message XSL, W3C Schema, and Response XSL (as applicable)

To continue the example above, you might create the following external system:

Head-End System

Outbound Message Type

Processing Method

XAI Sender

Message XSL /Response XSL

Commission Device

Real-time

Commission Device

OS-Request.xsl /

OS-Response.xsl

Decommission Device

Real-time

Decommission Device

OS-Request.xsl /

OS-Response.xsl

Device Status Check

Real-time

Device Status Check

OS-Request.xsl /

OS-Response.xsl

On-Demand Read

Real-time

On-Demand Read

OS-Request.xsl /

OS-Response.xsl

Remote Connect

Real-time

Connect Device

OS-Request.xsl /

OS-Response.xsl

Remote Disconnect

Real-time

Disconnect Device

OS-Request.xsl /

OS-Response.xsl

Refer to the Oracle Utilities Application Framework documentation for more information about external systems.

Configuring A Middleware Communication Layer

The last step in enabling the issuing of commands through Oracle Utilities Smart Grid Gateway from an external system is to configure a middleware component that sends web service requests from the external system to the XAI Inbound Services, and receives messages from the XAI Senders. This can via queue-based messaging such as JMS queues, or via tools such as Oracle SOA Suite and Business Process Execution Language (BPEL).

Creating Custom Smart Grid Gateway Adapters

This section provides an overview of the steps involved in creating custom adapters for use with Oracle Utilities Smart Grid Gateway. Adapters are configurations designed to support the specific communication requirements of a specific head-end system currently not supported by Oracle Utilities Smart Grid Gateway, and include:

•

Adapters for Importing Usage Readings and Device Events

•

Adapters for Issuing and Initiating Commands

•

Creating Custom Commands

The Oracle Utilities Smart Grid Gateway demonstration data includes a "generic" adapter that can be used as the basis for creating custom adapters. See Appendix D: The Oracle Utilities Smart Grid Gateway "Generic" Adapter for more information about the Oracle Utilities Smart Grid Gateway generic adapter.

Adapters for Importing Usage Readings and Device Events

This section outlines the steps involved in creating an adapter to support import of usage readings and device events from a head-end system. These steps include:

•

Configure Middleware

•

Create Business Objects

•

Create Service Provider for Head-End System

Configure Middleware

Middleware is used to facilitate communication between the head-end system and Oracle Utilities Smart Grid Gateway. In the case of importing usage readings and device events, the middleware performs the following steps:

•

Accepts payloads from head-end system

The middleware layer must be configured to accept payloads from the head-end system. This is often an queue-based process utilizing JMS queues configured within an application server.

•

Parses payloads into individual readings/events

Usage readings and device events are typically send data in payloads comprising hundreds or even thousands of readings or events. The middleware layer parses these payloads into individual readings or event, each of which is then processed separately.

•

Transforms readings/events from head-end system format into SGG format

Usage readings and device events are sent in a format used by the head-end system. The middleware layer transforms each reading or event from the head-end system format into the XML format used by Oracle Utilities Smart Grid Gateway. See Initial Measurement and Device Event XML Formats for details concerning this XML format.

•

Sends each reading or event to Oracle Utilities Smart Grid Gateway by invoking an XAI Inbound Service

After parsing and transforming the incoming data, the middleware then sends each reading or event to the application. This can be done via web service call to an XAI Inbound Service or by depositing the reading or event in a JMS queue.

•

Creates upload statistics activities to record the processing of each payload

As it processes each payload (including all the steps above), the middleware creates upload statistics activities as follows:

•

When processing begins for a payload, a Payload Statistics activity is created to record the process.

•

If an error occurs during processing, a Payload Error Notification activity is created.

•

When payload processing is complete, a Payload Summary activity is created, which in turn, updates the Payload Statistics activity with details concerning the processing of the payload.

See Upload Statistics for more information about upload statistics activities.

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus (OSB) to perform these operations. Refer to the following documentation for more details concerning the specific configurations of Oracle Service Bus used by Oracle Utilities Smart Gird Gateway adapters for importing usage reading and device events:

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr Configuration Guide

•

Oracle Utilities Smart Grid Gateway MV90 Adapter for Itron Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Echelon NES Configuration Guide

Pre-configured OSB processes can be extended to support custom requirements during processing.

Create Business Objects

For each type of usage reading and/or device event to be imported, you need to create business object that defines the initial measurement or device event. If the head-end system uses specific device event names, units of measure, or condition codes, you may also need to create extendable lookup business objects that can be used to perform mapping between the head-end system codes and "standard" codes.

Initial Measurement Data Business Objects

Initial measurement data business objects defines the types of initial measurement data to be received from the head-end system. You must create an initial measurement data business object for each type of initial measurement data you expect to store. For example, the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr uses the following initial measurement data business objects:

Initial Measurement Data Business Object

Description

D3-InitialLoadIMDInterval (Landis+Gyr Initial Load IMD - Interval)

Used for interval initial measurement data received from Landis+Gyr.

D3-InitialLoadIMDScalar (Landis+Gyr Initial Load IMD - Scalar)

Used for scalar initial measurement data received from Landis+Gyr.

Notes:

•

All head-end system-specific inteval initial measurement data business objects should be child business objects of the D1-InitialLoadIMDInterval business object.

•

All head-end system-specific scalar initial measurement data business objects should be child business objects of the D1-InitialLoadIMDScalar business object.

See Initial Measurement Data In Detail for more information about initial measurement data business objects.

Measurement Business Objects

Measurement business objects represent the different types of final measurements to be stored in the system that originate from the head-end system. If final measurements need to capture head-end system-specific data elements, you should create a measurement business object to accomodate those data elements. See Measurements In Detail for more information about measurement business objects.

Device Event Business Objects

Device event business objects represent the different types of device events that can be sent by the head-end system. Some device events represent events that occur without a duration, such as a tampering alert, while other device events represent events with a duration, such as an outage (the duration being the time between the start and end of the outage period.

Oracle Utilities Smart Grid Gateway provides a set of basic device event business objects that can extended to support head-end system-specific device events.

•

Device events with no duration are defined using "standard" device event business objects.

•

Device events with a duration are defined using "paired event" business objects, with the first of the pair representing the start of the event, and the last of the pair representing the end of the event.

Notes:

•

All head-end system-specific device event business objects should be child business objects of the D1-DeviceEvent business object.

See Device Events In Detail for more information about device event business objects.

Extendable Lookup Business Objects

If the head-end system uses its own set of units of measure, or device event names, or condition codes, you can create extendable lookup business objects to perform mappings between the head-end system codes and the standard codes used by Oracle Utilities Smart Grid Gateway. You reference these business objects in processing methods defined for the service provider that represents the head-end system.

Refer to the Oracle Utilities Application Framework documentation for more information extendable lookups.

Create Service Provider for Head-End System

Each head-end system that communicates with Oracle Utilities Smart Grid Gateway should be defined as a service provider. The service provider’s processing roles and methods are used by many processes to determine the specific manner in which data is to be sent or received from the service provider. For example, the "Initial Measurement Creation" processing role defines the specific type of initial measurement data business object to use when creating initial measuremenst received from the head-end system.

For example, the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr could use the following service provider to represent the Landis+Gyr Command Center head-end system.

Attribute/Field

Value

Service Provider Business Object

Head-End System (D1-HeadEndSystem)

Service Provider

LG

Description

Landis+Gyr

External Reference ID

LG

External System

Landis+Gyr

Our Name/ID in Their System

AMI Device ID Type

Internal Meter Number

AMI Measuring Component ID Type

Channel ID

This service provider uses the following processing methods:

Processing Role

Processing Method

Initial Measurement Creation / How to create Initial Load IMD

D1-HowToCreateMCInformation (How To Create MC Related Information)

This processing method specifies the type of intial measurement data business object to use when creating initial measurements received from Landis+Gyr. (D3-InitialLoadIMDScalar)

Note: The processing methods can define a default initial measurement data business object, or can specify an initial measurement data business object for each Measuring Component Type.

UOM Mapping / How to map UOMs from L+G when creating IMDs

D1-HowToProcessDeviceInfo (How to Process Device Related Information)

This processing method specifies the extendable lookup business object to use when mapping Landis+Gyr UOM codes to SGG UOM codes.

(D3-HeadendUOMLookup)

Note: The processing methods can define a default extendable lookup business object, or can specify an extendable lookup business object for each Device Type.

Note: The table above only lists processing methods used in processing readings and device events.

Another processing role and method used in processing device events is described below

Processing Role

Processing Method

Device Event Mapping / How to Map Device Events

D1-HowToProcessDeviceInfo (How to Process Device Related Information)

This processing method specifies the extendable lookup business object to use when mapping Landis+Gyr device event names to "standard" device event names.

Note: The processing methods can define a default extendable lookup business object, or can specify an extendable lookup business object for each Device Type.

See Service Providers In Detail and Processing Methods In Detail for more information about service providers and processing methods.

Adapters for Importing Usage Readings and Device Events

This section outlines the steps involved in creating an adapter to support import of usage readings and device events from a head-end system. These steps include:

•

Configure Middleware

•

Create Business Objects

•

Create Service Provider for Head-End System

Configure Middleware

Middleware is used to facilitate communication between the head-end system and Oracle Utilities Smart Grid Gateway. In the case of importing usage readings and device events, the middleware performs the following steps:

•

Accepts payloads from head-end system

The middleware layer must be configured to accept payloads from the head-end system. This is often an queue-based process utilizing JMS queues configured within an application server.

•

Parses payloads into individual readings/events

Usage readings and device events are typically send data in payloads comprising hundreds or even thousands of readings or events. The middleware layer parses these payloads into individual readings or event, each of which is then processed separately.

•

Transforms readings/events from head-end system format into SGG format

Usage readings and device events are sent in a format used by the head-end system. The middleware layer transforms each reading or event from the head-end system format into the XML format used by Oracle Utilities Smart Grid Gateway. See Initial Measurement and Device Event XML Formats for details concerning this XML format.

•

Sends each reading or event to Oracle Utilities Smart Grid Gateway by invoking an XAI Inbound Service

After parsing and transforming the incoming data, the middleware then sends each reading or event to the application. This can be done via web service call to an XAI Inbound Service or by depositing the reading or event in a JMS queue.

•

Creates upload statistics activities to record the processing of each payload

As it processes each payload (including all the steps above), the middleware creates upload statistics activities as follows:

•

When processing begins for a payload, a Payload Statistics activity is created to record the process.

•

If an error occurs during processing, a Payload Error Notification activity is created.

•

When payload processing is complete, a Payload Summary activity is created, which in turn, updates the Payload Statistics activity with details concerning the processing of the payload.

See Upload Statistics for more information about upload statistics activities.

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus (OSB) to perform these operations. Refer to the following documentation for more details concerning the specific configurations of Oracle Service Bus used by Oracle Utilities Smart Gird Gateway adapters for importing usage reading and device events:

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr Configuration Guide

•

Oracle Utilities Smart Grid Gateway MV90 Adapter for Itron Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Echelon NES Configuration Guide

Pre-configured OSB processes can be extended to support custom requirements during processing.

Create Business Objects

For each type of usage reading and/or device event to be imported, you need to create business object that defines the initial measurement or device event. If the head-end system uses specific device event names, units of measure, or condition codes, you may also need to create extendable lookup business objects that can be used to perform mapping between the head-end system codes and "standard" codes.

Initial Measurement Data Business Objects

Initial measurement data business objects defines the types of initial measurement data to be received from the head-end system. You must create an initial measurement data business object for each type of initial measurement data you expect to store. For example, the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr uses the following initial measurement data business objects:

Initial Measurement Data Business Object

Description

D3-InitialLoadIMDInterval (Landis+Gyr Initial Load IMD - Interval)

Used for interval initial measurement data received from Landis+Gyr.

D3-InitialLoadIMDScalar (Landis+Gyr Initial Load IMD - Scalar)

Used for scalar initial measurement data received from Landis+Gyr.

Notes:

•

All head-end system-specific inteval initial measurement data business objects should be child business objects of the D1-InitialLoadIMDInterval business object.

•

All head-end system-specific scalar initial measurement data business objects should be child business objects of the D1-InitialLoadIMDScalar business object.

See Initial Measurement Data In Detail for more information about initial measurement data business objects.

Measurement Business Objects

Measurement business objects represent the different types of final measurements to be stored in the system that originate from the head-end system. If final measurements need to capture head-end system-specific data elements, you should create a measurement business object to accomodate those data elements. See Measurements In Detail for more information about measurement business objects.

Device Event Business Objects

Device event business objects represent the different types of device events that can be sent by the head-end system. Some device events represent events that occur without a duration, such as a tampering alert, while other device events represent events with a duration, such as an outage (the duration being the time between the start and end of the outage period.

Oracle Utilities Smart Grid Gateway provides a set of basic device event business objects that can extended to support head-end system-specific device events.

•

Device events with no duration are defined using "standard" device event business objects.

•

Device events with a duration are defined using "paired event" business objects, with the first of the pair representing the start of the event, and the last of the pair representing the end of the event.

Notes:

•

All head-end system-specific device event business objects should be child business objects of the D1-DeviceEvent business object.

See Device Events In Detail for more information about device event business objects.

Extendable Lookup Business Objects

If the head-end system uses its own set of units of measure, or device event names, or condition codes, you can create extendable lookup business objects to perform mappings between the head-end system codes and the standard codes used by Oracle Utilities Smart Grid Gateway. You reference these business objects in processing methods defined for the service provider that represents the head-end system.

Refer to the Oracle Utilities Application Framework documentation for more information extendable lookups.

Create Service Provider for Head-End System

Each head-end system that communicates with Oracle Utilities Smart Grid Gateway should be defined as a service provider. The service provider’s processing roles and methods are used by many processes to determine the specific manner in which data is to be sent or received from the service provider. For example, the "Initial Measurement Creation" processing role defines the specific type of initial measurement data business object to use when creating initial measuremenst received from the head-end system.

For example, the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr could use the following service provider to represent the Landis+Gyr Command Center head-end system.

Attribute/Field

Value

Service Provider Business Object

Head-End System (D1-HeadEndSystem)

Service Provider

LG

Description

Landis+Gyr

External Reference ID

LG

External System

Landis+Gyr

Our Name/ID in Their System

AMI Device ID Type

Internal Meter Number

AMI Measuring Component ID Type

Channel ID

This service provider uses the following processing methods:

Processing Role

Processing Method

Initial Measurement Creation / How to create Initial Load IMD

D1-HowToCreateMCInformation (How To Create MC Related Information)

This processing method specifies the type of intial measurement data business object to use when creating initial measurements received from Landis+Gyr. (D3-InitialLoadIMDScalar)

Note: The processing methods can define a default initial measurement data business object, or can specify an initial measurement data business object for each Measuring Component Type.

UOM Mapping / How to map UOMs from L+G when creating IMDs

D1-HowToProcessDeviceInfo (How to Process Device Related Information)

This processing method specifies the extendable lookup business object to use when mapping Landis+Gyr UOM codes to SGG UOM codes.

(D3-HeadendUOMLookup)

Note: The processing methods can define a default extendable lookup business object, or can specify an extendable lookup business object for each Device Type.

Note: The table above only lists processing methods used in processing readings and device events.

Another processing role and method used in processing device events is described below

Processing Role

Processing Method

Device Event Mapping / How to Map Device Events

D1-HowToProcessDeviceInfo (How to Process Device Related Information)

This processing method specifies the extendable lookup business object to use when mapping Landis+Gyr device event names to "standard" device event names.

Note: The processing methods can define a default extendable lookup business object, or can specify an extendable lookup business object for each Device Type.

See Service Providers In Detail and Processing Methods In Detail for more information about service providers and processing methods.

Adapters for Importing Usage Readings and Device Events

This section outlines the steps involved in creating an adapter to support import of usage readings and device events from a head-end system. These steps include:

•

Configure Middleware

•

Create Business Objects

•

Create Service Provider for Head-End System

Configure Middleware

Middleware is used to facilitate communication between the head-end system and Oracle Utilities Smart Grid Gateway. In the case of importing usage readings and device events, the middleware performs the following steps:

•

Accepts payloads from head-end system

The middleware layer must be configured to accept payloads from the head-end system. This is often an queue-based process utilizing JMS queues configured within an application server.

•

Parses payloads into individual readings/events

Usage readings and device events are typically send data in payloads comprising hundreds or even thousands of readings or events. The middleware layer parses these payloads into individual readings or event, each of which is then processed separately.

•

Transforms readings/events from head-end system format into SGG format

Usage readings and device events are sent in a format used by the head-end system. The middleware layer transforms each reading or event from the head-end system format into the XML format used by Oracle Utilities Smart Grid Gateway. See Initial Measurement and Device Event XML Formats for details concerning this XML format.

•

Sends each reading or event to Oracle Utilities Smart Grid Gateway by invoking an XAI Inbound Service

After parsing and transforming the incoming data, the middleware then sends each reading or event to the application. This can be done via web service call to an XAI Inbound Service or by depositing the reading or event in a JMS queue.

•

Creates upload statistics activities to record the processing of each payload

As it processes each payload (including all the steps above), the middleware creates upload statistics activities as follows:

•

When processing begins for a payload, a Payload Statistics activity is created to record the process.

•

If an error occurs during processing, a Payload Error Notification activity is created.

•

When payload processing is complete, a Payload Summary activity is created, which in turn, updates the Payload Statistics activity with details concerning the processing of the payload.

See Upload Statistics for more information about upload statistics activities.

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus (OSB) to perform these operations. Refer to the following documentation for more details concerning the specific configurations of Oracle Service Bus used by Oracle Utilities Smart Gird Gateway adapters for importing usage reading and device events:

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr Configuration Guide

•

Oracle Utilities Smart Grid Gateway MV90 Adapter for Itron Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Echelon NES Configuration Guide

Pre-configured OSB processes can be extended to support custom requirements during processing.

Create Business Objects

For each type of usage reading and/or device event to be imported, you need to create business object that defines the initial measurement or device event. If the head-end system uses specific device event names, units of measure, or condition codes, you may also need to create extendable lookup business objects that can be used to perform mapping between the head-end system codes and "standard" codes.

Initial Measurement Data Business Objects

Initial measurement data business objects defines the types of initial measurement data to be received from the head-end system. You must create an initial measurement data business object for each type of initial measurement data you expect to store. For example, the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr uses the following initial measurement data business objects:

Initial Measurement Data Business Object

Description

D3-InitialLoadIMDInterval (Landis+Gyr Initial Load IMD - Interval)

Used for interval initial measurement data received from Landis+Gyr.

D3-InitialLoadIMDScalar (Landis+Gyr Initial Load IMD - Scalar)

Used for scalar initial measurement data received from Landis+Gyr.

Notes:

•

All head-end system-specific inteval initial measurement data business objects should be child business objects of the D1-InitialLoadIMDInterval business object.

•

All head-end system-specific scalar initial measurement data business objects should be child business objects of the D1-InitialLoadIMDScalar business object.

See Initial Measurement Data In Detail for more information about initial measurement data business objects.

Measurement Business Objects

Measurement business objects represent the different types of final measurements to be stored in the system that originate from the head-end system. If final measurements need to capture head-end system-specific data elements, you should create a measurement business object to accomodate those data elements. See Measurements In Detail for more information about measurement business objects.

Device Event Business Objects

Device event business objects represent the different types of device events that can be sent by the head-end system. Some device events represent events that occur without a duration, such as a tampering alert, while other device events represent events with a duration, such as an outage (the duration being the time between the start and end of the outage period.

Oracle Utilities Smart Grid Gateway provides a set of basic device event business objects that can extended to support head-end system-specific device events.

•

Device events with no duration are defined using "standard" device event business objects.

•

Device events with a duration are defined using "paired event" business objects, with the first of the pair representing the start of the event, and the last of the pair representing the end of the event.

Notes:

•

All head-end system-specific device event business objects should be child business objects of the D1-DeviceEvent business object.

See Device Events In Detail for more information about device event business objects.

Extendable Lookup Business Objects

If the head-end system uses its own set of units of measure, or device event names, or condition codes, you can create extendable lookup business objects to perform mappings between the head-end system codes and the standard codes used by Oracle Utilities Smart Grid Gateway. You reference these business objects in processing methods defined for the service provider that represents the head-end system.

Refer to the Oracle Utilities Application Framework documentation for more information extendable lookups.

Create Service Provider for Head-End System

Each head-end system that communicates with Oracle Utilities Smart Grid Gateway should be defined as a service provider. The service provider’s processing roles and methods are used by many processes to determine the specific manner in which data is to be sent or received from the service provider. For example, the "Initial Measurement Creation" processing role defines the specific type of initial measurement data business object to use when creating initial measuremenst received from the head-end system.

For example, the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr could use the following service provider to represent the Landis+Gyr Command Center head-end system.

Attribute/Field

Value

Service Provider Business Object

Head-End System (D1-HeadEndSystem)

Service Provider

LG

Description

Landis+Gyr

External Reference ID

LG

External System

Landis+Gyr

Our Name/ID in Their System

AMI Device ID Type

Internal Meter Number

AMI Measuring Component ID Type

Channel ID

This service provider uses the following processing methods:

Processing Role

Processing Method

Initial Measurement Creation / How to create Initial Load IMD

D1-HowToCreateMCInformation (How To Create MC Related Information)

This processing method specifies the type of intial measurement data business object to use when creating initial measurements received from Landis+Gyr. (D3-InitialLoadIMDScalar)

Note: The processing methods can define a default initial measurement data business object, or can specify an initial measurement data business object for each Measuring Component Type.

UOM Mapping / How to map UOMs from L+G when creating IMDs

D1-HowToProcessDeviceInfo (How to Process Device Related Information)

This processing method specifies the extendable lookup business object to use when mapping Landis+Gyr UOM codes to SGG UOM codes.

(D3-HeadendUOMLookup)

Note: The processing methods can define a default extendable lookup business object, or can specify an extendable lookup business object for each Device Type.

Note: The table above only lists processing methods used in processing readings and device events.

Another processing role and method used in processing device events is described below

Processing Role

Processing Method

Device Event Mapping / How to Map Device Events

D1-HowToProcessDeviceInfo (How to Process Device Related Information)

This processing method specifies the extendable lookup business object to use when mapping Landis+Gyr device event names to "standard" device event names.

Note: The processing methods can define a default extendable lookup business object, or can specify an extendable lookup business object for each Device Type.

See Service Providers In Detail and Processing Methods In Detail for more information about service providers and processing methods.

Adapters for Importing Usage Readings and Device Events

This section outlines the steps involved in creating an adapter to support import of usage readings and device events from a head-end system. These steps include:

•

Configure Middleware

•

Create Business Objects

•

Create Service Provider for Head-End System

Configure Middleware

Middleware is used to facilitate communication between the head-end system and Oracle Utilities Smart Grid Gateway. In the case of importing usage readings and device events, the middleware performs the following steps:

•

Accepts payloads from head-end system

The middleware layer must be configured to accept payloads from the head-end system. This is often an queue-based process utilizing JMS queues configured within an application server.

•

Parses payloads into individual readings/events

Usage readings and device events are typically send data in payloads comprising hundreds or even thousands of readings or events. The middleware layer parses these payloads into individual readings or event, each of which is then processed separately.

•

Transforms readings/events from head-end system format into SGG format

Usage readings and device events are sent in a format used by the head-end system. The middleware layer transforms each reading or event from the head-end system format into the XML format used by Oracle Utilities Smart Grid Gateway. See Initial Measurement and Device Event XML Formats for details concerning this XML format.

•

Sends each reading or event to Oracle Utilities Smart Grid Gateway by invoking an XAI Inbound Service

After parsing and transforming the incoming data, the middleware then sends each reading or event to the application. This can be done via web service call to an XAI Inbound Service or by depositing the reading or event in a JMS queue.

•

Creates upload statistics activities to record the processing of each payload

As it processes each payload (including all the steps above), the middleware creates upload statistics activities as follows:

•

When processing begins for a payload, a Payload Statistics activity is created to record the process.

•

If an error occurs during processing, a Payload Error Notification activity is created.

•

When payload processing is complete, a Payload Summary activity is created, which in turn, updates the Payload Statistics activity with details concerning the processing of the payload.

See Upload Statistics for more information about upload statistics activities.

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus (OSB) to perform these operations. Refer to the following documentation for more details concerning the specific configurations of Oracle Service Bus used by Oracle Utilities Smart Gird Gateway adapters for importing usage reading and device events:

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr Configuration Guide

•

Oracle Utilities Smart Grid Gateway MV90 Adapter for Itron Configuration Guide

•

Oracle Utilities Smart Grid Gateway Adapter for Echelon NES Configuration Guide

Pre-configured OSB processes can be extended to support custom requirements during processing.

Create Business Objects

For each type of usage reading and/or device event to be imported, you need to create business object that defines the initial measurement or device event. If the head-end system uses specific device event names, units of measure, or condition codes, you may also need to create extendable lookup business objects that can be used to perform mapping between the head-end system codes and "standard" codes.

Initial Measurement Data Business Objects

Initial measurement data business objects defines the types of initial measurement data to be received from the head-end system. You must create an initial measurement data business object for each type of initial measurement data you expect to store. For example, the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr uses the following initial measurement data business objects:

Initial Measurement Data Business Object

Description

D3-InitialLoadIMDInterval (Landis+Gyr Initial Load IMD - Interval)

Used for interval initial measurement data received from Landis+Gyr.

D3-InitialLoadIMDScalar (Landis+Gyr Initial Load IMD - Scalar)

Used for scalar initial measurement data received from Landis+Gyr.

Notes:

•

All head-end system-specific inteval initial measurement data business objects should be child business objects of the D1-InitialLoadIMDInterval business object.

•

All head-end system-specific scalar initial measurement data business objects should be child business objects of the D1-InitialLoadIMDScalar business object.

See Initial Measurement Data In Detail for more information about initial measurement data business objects.

Measurement Business Objects

Measurement business objects represent the different types of final measurements to be stored in the system that originate from the head-end system. If final measurements need to capture head-end system-specific data elements, you should create a measurement business object to accomodate those data elements. See Measurements In Detail for more information about measurement business objects.

Device Event Business Objects

Device event business objects represent the different types of device events that can be sent by the head-end system. Some device events represent events that occur without a duration, such as a tampering alert, while other device events represent events with a duration, such as an outage (the duration being the time between the start and end of the outage period.

Oracle Utilities Smart Grid Gateway provides a set of basic device event business objects that can extended to support head-end system-specific device events.

•

Device events with no duration are defined using "standard" device event business objects.

•

Device events with a duration are defined using "paired event" business objects, with the first of the pair representing the start of the event, and the last of the pair representing the end of the event.

Notes:

•

All head-end system-specific device event business objects should be child business objects of the D1-DeviceEvent business object.

See Device Events In Detail for more information about device event business objects.

Extendable Lookup Business Objects

If the head-end system uses its own set of units of measure, or device event names, or condition codes, you can create extendable lookup business objects to perform mappings between the head-end system codes and the standard codes used by Oracle Utilities Smart Grid Gateway. You reference these business objects in processing methods defined for the service provider that represents the head-end system.

Refer to the Oracle Utilities Application Framework documentation for more information extendable lookups.

Create Service Provider for Head-End System

Each head-end system that communicates with Oracle Utilities Smart Grid Gateway should be defined as a service provider. The service provider’s processing roles and methods are used by many processes to determine the specific manner in which data is to be sent or received from the service provider. For example, the "Initial Measurement Creation" processing role defines the specific type of initial measurement data business object to use when creating initial measuremenst received from the head-end system.

For example, the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr could use the following service provider to represent the Landis+Gyr Command Center head-end system.

Attribute/Field

Value

Service Provider Business Object

Head-End System (D1-HeadEndSystem)

Service Provider

LG

Description

Landis+Gyr

External Reference ID

LG

External System

Landis+Gyr

Our Name/ID in Their System

AMI Device ID Type

Internal Meter Number

AMI Measuring Component ID Type

Channel ID

This service provider uses the following processing methods:

Processing Role

Processing Method

Initial Measurement Creation / How to create Initial Load IMD

D1-HowToCreateMCInformation (How To Create MC Related Information)

This processing method specifies the type of intial measurement data business object to use when creating initial measurements received from Landis+Gyr. (D3-InitialLoadIMDScalar)

Note: The processing methods can define a default initial measurement data business object, or can specify an initial measurement data business object for each Measuring Component Type.

UOM Mapping / How to map UOMs from L+G when creating IMDs

D1-HowToProcessDeviceInfo (How to Process Device Related Information)

This processing method specifies the extendable lookup business object to use when mapping Landis+Gyr UOM codes to SGG UOM codes.

(D3-HeadendUOMLookup)

Note: The processing methods can define a default extendable lookup business object, or can specify an extendable lookup business object for each Device Type.

Note: The table above only lists processing methods used in processing readings and device events.

Another processing role and method used in processing device events is described below

Processing Role

Processing Method

Device Event Mapping / How to Map Device Events

D1-HowToProcessDeviceInfo (How to Process Device Related Information)

This processing method specifies the extendable lookup business object to use when mapping Landis+Gyr device event names to "standard" device event names.

Note: The processing methods can define a default extendable lookup business object, or can specify an extendable lookup business object for each Device Type.

See Service Providers In Detail and Processing Methods In Detail for more information about service providers and processing methods.

Adapters for Issuing and Initiating Commands

This section outlines the steps involved in creating an adapter to support initiating commands and communications between Oracle Utilities Smart Grid Gateway and a head-end system. These steps include:

•

Configure Outbound Communication

•

Configure Middleware

•

Configure Inbound Communication

•

Create Service Provider for Head-End System

•

Creating Custom Commands

Configure Outbound Communication

Outbound Communications represent messages sent from Oracle Utilities Smart Grid Gateway to the head-end system or edge application (such as Oracle Customer Care and Billing). Outbound communications use the following types of objects:

•

Outbound Communication Business Objects

•

Outbound Message Types

•

XAI Senders

•

External Systems

Outbound Communication Business Objects

Outbound communication business object must be created for each type of message to be sent to the head-end system. This is based on the types of messages the system is designed to accept. For example, suppose a head-end system supports the following types of commands: device commission, device decommission, device status check, on-demand readings, remote connect, and remote disconnect, and that this head-end system accepts a separate type of message for each command. For this example, you would need to create outbound communication business objects for each command, as follows:

Command

Outbound Communication Business Object

Commission Device

Commission Device Outbound Communication

Decommission Device

Decommission Device Outbound Communication

Device Status Check

Device Status Check Outbound Communication

On-Demand Read

On-Demand Read Outbound Communication

Remote Connect

Remote Connect Outbound Communication

Remote Disconnect

Remote Disconnect Outbound Communication

The specifics of each business object are based on the type of message to be sent to the head-end system. The table below provides an example of the "Initiate Connect Disconnect" outbound communication business object used by the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr.

Option

Description

Business Object

D3-InitiateConnectDisconnect

Description

Initiate Connect Disconnect

Maintenance Object

D1-COMMOUT (Communication Out)

Application Service

D3-INITIATECONDISCON (Initiate Connect Disconnect)

Instance Control

Allow New Instances

Options

•

Related Administration BO: D3-InitiateConnectDisconType (Initiate Connect Disconnect Type)

•

Display UI Map: D3-InitConDisconMltSpkDisplay (Initiate Connect Disconnect Display)

•

Portal Navigation Option: d1OBCommunicationNavOpt (Outbound Communication Navigation Option)

•

Display Map Service Script: D3-RtICDDtls (Connect Disconnect - Retrieve Details for Display)

•

Maintenance Map UI Map: D3-InitConDisconMltSpkMaint (Connect Disconnect Maintenance)

Algorithms

•

Information: D1-COMMINFO (Communication Information)

•

Pre-Processing: D3-GDRFFPA (Default required fields from Parent Activity)

•

Pre-Processing: D3-DLAC (Default Load Action Check)

Lifecycle / Algorithms

Note: Does not include "Transition to Default Next Status" monitor algorithms.

•

Pending

•

Validate

•

Enter: D1-VALCOMTP (Validate Communication Type)

•

Validation Error

•

Monitor: D1-RBOE (Rety BO in Error)

•

Enter: D1-CTDEBOE (Create To Do Entry for BO in Error)

•

Exit: D1-GTDCBO (Generic To Do Completion for BOs)

•

Awaiting Response

•

Monitor: D1-TIMEOUT (Time Out)

•

Enter: D3-PICDSD (Populate Initial Connect Disconnect Send Detail)

•

Enter: D3-CCDOBTMSG (Create Connect/Disconnect Out Bound Message)

•

Retry

•

Response Error

•

Same as Validation Error (above)

•

Discarded

•

Enter: D1-TPATOF (Transition Parent Activity to Failed)

•

Completed

•

Enter: D3-UCCDFTPA (Update Connect Disconnect Completion Flag And Transition Parent Activity)

Outbound Message Types

A outbound message type must also be created for each type of message to be sent to the head-end system. Again, this is based on the types of messages the head-end system is designed to accept. To continue the example above, you might create the following outbound message types:

Command

Outbound Message Type

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read

On-Demand Read

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about outbound message types.

XAI Senders

You must also create an XAI Sender for each type of message to be sent to an external system. XAI senders define the details of how messages are sent to an external system. As in the case of outbound communication business objects and outbound message types, the set of XAI senders you need to create is based on the types of messages the head-end system is designed to accept. To continue the example above, you might create the following XAI senders:

Command

XAI Sender

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read

On-Demand Read

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about XAI senders.

External Systems

You must also create an External System for each external system to which Oracle Utilities Smart Grid Gateway will send messages. Each external system defines a set of outbound message types that will be sent to that system. The external system also specifies the following for each outbound message type:

•

The outbound message type

•

The processing method used to send the message (Batch, XAI, or Real-time)

•

The corresponding XAI senders

•

Batch Control (if Processing Method is set to Batch)

•

Message XSL, W3C Schema, and Response XSL (as applicable)

To continue the example above, you might create the following external system:

Head-End System

Outbound Message Type

Processing Method

XAI Sender

Message XSL /Response XSL

Commission Device

Real-time

Commission Device

HES-Request.xsl /

HES-Response.xsl

Decommission Device

Real-time

Decommission Device

HES-Request.xsl /

HES-Response.xsl

Device Status Check

Real-time

Device Status Check

HES-Request.xsl /

HES-Response.xsl

On-Demand Read

Real-time

On-Demand Read

HES-Request.xsl /

HES-Response.xsl

Remote Connect

Real-time

Connect Device

HES-Request.xsl /

HES-Response.xsl

Remote Disconnect

Real-time

Disconnect Device

HES-Request.xsl /

HES-Response.xsl

Refer to the Oracle Utilities Application Framework documentation for more information about external systems.

Configure Middleware

Middleware is used to facilitate communication between the head-end system and Oracle Utilities Smart Grid Gateway. In the case of processing commands, the middleware performs the following steps:

•

Accepts outbound messages from XAI Senders

The middleware must monitor the XAI senders configured to send messages from Oracle Utilities Smart Grid Gateway to the head-end system.

•

Transforms communications from SGG format into head-end system format

Messages are sent in a standard format used by Oracle Utilities Smart Grid Gateway. The middleware must transform each message from this standard format into the format used by the head-end system.

•

Sends messages to the head-end system

The middleware must then send the transformed message to the head-end system. In Oracle Utilities Smart Grid Gateway adapters, this is done via a web service call to web services defined for the head-end system.

•

Receives responses from the head-end system

The middleware also receives responses from the head-end system that indicate if the command was successfully carried out.

•

Transforms communications from head-end system format into SGG format

Response messages are sent in a format used by the head-end system. The middleware must transform each message from this format into the standard format used by Oracle Utilities Smart Grid Gateway.

•

Sends response message to Oracle Utilities Smart Grid Gateway by invoking an XAI Inbound Service

The middleware then sends the response message to the application. This can be done via web service call to an XAI Inbound Service or by depositing the message in a JMS queue.

Oracle Utilities Smart Grid Gateway adapters use Oracle Business Process Exeecution Language (BPEL) to perform these operations. Refer to the following documentation for more details concerning the specific configurations of BPEL used by Oracle Utilities Smart Gird Gateway adapters for processing commands:

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr Configuration Guide

Pre-configured BPEL processes can be extended to support custom requirements during message processing.

Configure Inbound Communication

Inbound Communications represent messages sent from a head-end system or edge application (such as Oracle Customer Care and Billing) to Oracle Utilities Smart Grid Gateway. Inbound communications are typically sent in response to a command. Inbound communications use the following types of objects:

•

Inbound Communication Business Objects

•

XAI Inbound Services

Inbound Communication Business Objects

An inbound communication business object must be created for each type of message to be received from the head-end systems, based on the types of messages the system is designed to send. To continue the above example, a head-end system that supports the types of commands outlined above (device commission, device decommission, device status check, on-demand readings, remote connect, and remote disconnect) might send a separate type of message in response to each command. For this example, you would need to create the following inbound communication business objects:

Command Being Responded To

Inbound Communication Business Object

Commission Device

Commission Device Response

Decommission Device

Decommission Device Response

Device Status Check

Device Status Check Response

On-Demand Read

On-Demand Read Response

Remote Connect

Remote Connect Response

Remote Disconnect

Remote Disconnect Response

The specifics of each business object are based on the type of message to be sent to the head-end system. The table below provides an example of the "Connect Disconnect State Changed Notification (Multispeak)" inbound communication business object used by the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr.

Option

Description

Business Object

D3-ConnectDisconStateChgNtf

Description

Connect Disconnect State Changed Notification (Multispeak)

Maintenance Object

D1-COMMIN (Communication In)

Application Service

D3-CONDISSTCHGNTBOAS (State Change Notification BO)

Instance Control

Allow New Instances

Options

•

Related Administration BO: D3-ConnectDisconStateChgNtfTyp (Connect Disconnect State Change Notify Type)

•

Display UI Map: D3-ConDisconStChgMltSpkDisplay (State Change Notification - Display)

•

Portal Navigation Option: d1IBCommunicationNavOpt (Inbound Communication Navigation Option)

•

Display Map Service Script: D3-RtSCNDtls (State Change - Retrieve Details for Display)

•

Maintenance Map UI Map: D3-ConDisconStChgMltSpkMaint (State Change Notification - Maintenance)

Algorithms

•

Information: D1-COMMINFO (Communication Information)

•

Pre-Processing: D3-SETDFBOEC (Set Default BO elements - Connect/Disconnect Notification)

Lifecycle / Algorithms

Note: Does not include "Transition to Default Next Status" monitor algorithms.

•

Pending

•

Validate

•

Enter: D3-FPCBORC (Find Parent Communication BO Remote Connect)

•

Enter: D1-VALCOMTP (Validate Communication Type)

•

Enter: D3-VSCC (Validate State Change Code)

•

Validation Error

•

Monitor: D1-RBOE (Rety BO in Error)

•

Enter: D1-CTDEBOE (Create To Do Entry for BO in Error)

•

Exit: D1-GTDCBO (Generic To Do Completion for BOs)

•

Discarded

•

Enter: D3-FAILPCOUT (Fail Parent Outbound Communication)

•

Create Completion Event

•

D3-CCE (Create Completion Event)

•

Completed

•

Enter: D3-UPCMEVDTR (Update Parent Communication’s Event Date Time Connect)

•

Enter: D3-TRANPRBO (Transition Parent Outbound Communication BO)

XAI Inbound Services

You must also create an XAI Inbound Service for each type of message to be received from an external system. XAI inbound systems define the details of how messages are received from an external system, including the inbound communication business object (or business service or service script) to be invoked when the response message is received. As in the case of inbound communication business objects, the set of XAI inbound services you need to create is based on the types of messages the system is designed to send. To continue the example above, you might create the following XAI inbound services:

XAI Inbound Service

Schema

(Inbound Communication Business Object)

Commission Device Response

Commission Device Response

Decommission Device Response

Decommission Device Response

Device Status Check Response

Device Status Check Response

On-Demand Read Response

On-Demand Read Response

Connect Device Response

Remote Connect Response

Disconnect Device Response

Remote Disconnect Response

Refer to the Oracle Utilities Application Framework documentation for more information about XAI Inbound Services.

Create Service Provider for Head-End System

Each head-end system that communicates with Oracle Utilities Smart Grid Gateway should be defined as a service provider. The service provider’s processing roles and methods are used by many processes to determine the specific manner in which data is to be sent or received from the service provider. For example, the "Remote Connect" processing role defines the specific type of outbound communication business object to use when sending outbound communications to the head-end system as a result of a remote connect command.

The Landis+Gyr service provider provided with the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr uses the following processing methods:

Processing Role

Processing Method

On-Demand Read (Scalar) (D1SC)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to Landis+Gyr as a result of an on-demand read (scalar) command. (D3-InitiateMRByMtrNbr / Initiate Meter Read By Meter Number (CMD3))

Remote Connect (D1RC)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to Landis+Gyr as a result of a remote connect command. (D3-InitiateConnectDisconnect / Connect Device (D3-CONNECT))

Remote Disconnect (D1RD)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to Landis+Gyr as a result of a remote connect command. (D3-InitiateConnectDisconnect / Disconnect Device (D3-DISCONNEC))

Note: The table above only lists processing methods used in processing commands.

Command processing methods can define a default outbound communication business object/outbound message type, or can specify an outbound communication business object/outbound message type for each Device Type.

Other processing roles and methods used in processing commands are described below

Processing Role

Processing Method

Device Commission (D1DC)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of a commission device command.

Device Decommission (D1DD)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of a decommission device command.

Device Status Check (D1DS)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of a device status check command.

On-Demand Read (Interval) (D1IN)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of an on-demand read (interval) command.

See Service Providers In Detail and Processing Methods In Detail for more information about service providers and processing methods.

Adapters for Issuing and Initiating Commands

This section outlines the steps involved in creating an adapter to support initiating commands and communications between Oracle Utilities Smart Grid Gateway and a head-end system. These steps include:

•

Configure Outbound Communication

•

Configure Middleware

•

Configure Inbound Communication

•

Create Service Provider for Head-End System

•

Creating Custom Commands

Configure Outbound Communication

Outbound Communications represent messages sent from Oracle Utilities Smart Grid Gateway to the head-end system or edge application (such as Oracle Customer Care and Billing). Outbound communications use the following types of objects:

•

Outbound Communication Business Objects

•

Outbound Message Types

•

XAI Senders

•

External Systems

Outbound Communication Business Objects

Outbound communication business object must be created for each type of message to be sent to the head-end system. This is based on the types of messages the system is designed to accept. For example, suppose a head-end system supports the following types of commands: device commission, device decommission, device status check, on-demand readings, remote connect, and remote disconnect, and that this head-end system accepts a separate type of message for each command. For this example, you would need to create outbound communication business objects for each command, as follows:

Command

Outbound Communication Business Object

Commission Device

Commission Device Outbound Communication

Decommission Device

Decommission Device Outbound Communication

Device Status Check

Device Status Check Outbound Communication

On-Demand Read

On-Demand Read Outbound Communication

Remote Connect

Remote Connect Outbound Communication

Remote Disconnect

Remote Disconnect Outbound Communication

The specifics of each business object are based on the type of message to be sent to the head-end system. The table below provides an example of the "Initiate Connect Disconnect" outbound communication business object used by the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr.

Option

Description

Business Object

D3-InitiateConnectDisconnect

Description

Initiate Connect Disconnect

Maintenance Object

D1-COMMOUT (Communication Out)

Application Service

D3-INITIATECONDISCON (Initiate Connect Disconnect)

Instance Control

Allow New Instances

Options

•

Related Administration BO: D3-InitiateConnectDisconType (Initiate Connect Disconnect Type)

•

Display UI Map: D3-InitConDisconMltSpkDisplay (Initiate Connect Disconnect Display)

•

Portal Navigation Option: d1OBCommunicationNavOpt (Outbound Communication Navigation Option)

•

Display Map Service Script: D3-RtICDDtls (Connect Disconnect - Retrieve Details for Display)

•

Maintenance Map UI Map: D3-InitConDisconMltSpkMaint (Connect Disconnect Maintenance)

Algorithms

•

Information: D1-COMMINFO (Communication Information)

•

Pre-Processing: D3-GDRFFPA (Default required fields from Parent Activity)

•

Pre-Processing: D3-DLAC (Default Load Action Check)

Lifecycle / Algorithms

Note: Does not include "Transition to Default Next Status" monitor algorithms.

•

Pending

•

Validate

•

Enter: D1-VALCOMTP (Validate Communication Type)

•

Validation Error

•

Monitor: D1-RBOE (Rety BO in Error)

•

Enter: D1-CTDEBOE (Create To Do Entry for BO in Error)

•

Exit: D1-GTDCBO (Generic To Do Completion for BOs)

•

Awaiting Response

•

Monitor: D1-TIMEOUT (Time Out)

•

Enter: D3-PICDSD (Populate Initial Connect Disconnect Send Detail)

•

Enter: D3-CCDOBTMSG (Create Connect/Disconnect Out Bound Message)

•

Retry

•

Response Error

•

Same as Validation Error (above)

•

Discarded

•

Enter: D1-TPATOF (Transition Parent Activity to Failed)

•

Completed

•

Enter: D3-UCCDFTPA (Update Connect Disconnect Completion Flag And Transition Parent Activity)

Outbound Message Types

A outbound message type must also be created for each type of message to be sent to the head-end system. Again, this is based on the types of messages the head-end system is designed to accept. To continue the example above, you might create the following outbound message types:

Command

Outbound Message Type

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read

On-Demand Read

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about outbound message types.

XAI Senders

You must also create an XAI Sender for each type of message to be sent to an external system. XAI senders define the details of how messages are sent to an external system. As in the case of outbound communication business objects and outbound message types, the set of XAI senders you need to create is based on the types of messages the head-end system is designed to accept. To continue the example above, you might create the following XAI senders:

Command

XAI Sender

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read

On-Demand Read

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about XAI senders.

External Systems

You must also create an External System for each external system to which Oracle Utilities Smart Grid Gateway will send messages. Each external system defines a set of outbound message types that will be sent to that system. The external system also specifies the following for each outbound message type:

•

The outbound message type

•

The processing method used to send the message (Batch, XAI, or Real-time)

•

The corresponding XAI senders

•

Batch Control (if Processing Method is set to Batch)

•

Message XSL, W3C Schema, and Response XSL (as applicable)

To continue the example above, you might create the following external system:

Head-End System

Outbound Message Type

Processing Method

XAI Sender

Message XSL /Response XSL

Commission Device

Real-time

Commission Device

HES-Request.xsl /

HES-Response.xsl

Decommission Device

Real-time

Decommission Device

HES-Request.xsl /

HES-Response.xsl

Device Status Check

Real-time

Device Status Check

HES-Request.xsl /

HES-Response.xsl

On-Demand Read

Real-time

On-Demand Read

HES-Request.xsl /

HES-Response.xsl

Remote Connect

Real-time

Connect Device

HES-Request.xsl /

HES-Response.xsl

Remote Disconnect

Real-time

Disconnect Device

HES-Request.xsl /

HES-Response.xsl

Refer to the Oracle Utilities Application Framework documentation for more information about external systems.

Configure Middleware

Middleware is used to facilitate communication between the head-end system and Oracle Utilities Smart Grid Gateway. In the case of processing commands, the middleware performs the following steps:

•

Accepts outbound messages from XAI Senders

The middleware must monitor the XAI senders configured to send messages from Oracle Utilities Smart Grid Gateway to the head-end system.

•

Transforms communications from SGG format into head-end system format

Messages are sent in a standard format used by Oracle Utilities Smart Grid Gateway. The middleware must transform each message from this standard format into the format used by the head-end system.

•

Sends messages to the head-end system

The middleware must then send the transformed message to the head-end system. In Oracle Utilities Smart Grid Gateway adapters, this is done via a web service call to web services defined for the head-end system.

•

Receives responses from the head-end system

The middleware also receives responses from the head-end system that indicate if the command was successfully carried out.

•

Transforms communications from head-end system format into SGG format

Response messages are sent in a format used by the head-end system. The middleware must transform each message from this format into the standard format used by Oracle Utilities Smart Grid Gateway.

•

Sends response message to Oracle Utilities Smart Grid Gateway by invoking an XAI Inbound Service

The middleware then sends the response message to the application. This can be done via web service call to an XAI Inbound Service or by depositing the message in a JMS queue.

Oracle Utilities Smart Grid Gateway adapters use Oracle Business Process Exeecution Language (BPEL) to perform these operations. Refer to the following documentation for more details concerning the specific configurations of BPEL used by Oracle Utilities Smart Gird Gateway adapters for processing commands:

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr Configuration Guide

Pre-configured BPEL processes can be extended to support custom requirements during message processing.

Configure Inbound Communication

Inbound Communications represent messages sent from a head-end system or edge application (such as Oracle Customer Care and Billing) to Oracle Utilities Smart Grid Gateway. Inbound communications are typically sent in response to a command. Inbound communications use the following types of objects:

•

Inbound Communication Business Objects

•

XAI Inbound Services

Inbound Communication Business Objects

An inbound communication business object must be created for each type of message to be received from the head-end systems, based on the types of messages the system is designed to send. To continue the above example, a head-end system that supports the types of commands outlined above (device commission, device decommission, device status check, on-demand readings, remote connect, and remote disconnect) might send a separate type of message in response to each command. For this example, you would need to create the following inbound communication business objects:

Command Being Responded To

Inbound Communication Business Object

Commission Device

Commission Device Response

Decommission Device

Decommission Device Response

Device Status Check

Device Status Check Response

On-Demand Read

On-Demand Read Response

Remote Connect

Remote Connect Response

Remote Disconnect

Remote Disconnect Response

The specifics of each business object are based on the type of message to be sent to the head-end system. The table below provides an example of the "Connect Disconnect State Changed Notification (Multispeak)" inbound communication business object used by the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr.

Option

Description

Business Object

D3-ConnectDisconStateChgNtf

Description

Connect Disconnect State Changed Notification (Multispeak)

Maintenance Object

D1-COMMIN (Communication In)

Application Service

D3-CONDISSTCHGNTBOAS (State Change Notification BO)

Instance Control

Allow New Instances

Options

•

Related Administration BO: D3-ConnectDisconStateChgNtfTyp (Connect Disconnect State Change Notify Type)

•

Display UI Map: D3-ConDisconStChgMltSpkDisplay (State Change Notification - Display)

•

Portal Navigation Option: d1IBCommunicationNavOpt (Inbound Communication Navigation Option)

•

Display Map Service Script: D3-RtSCNDtls (State Change - Retrieve Details for Display)

•

Maintenance Map UI Map: D3-ConDisconStChgMltSpkMaint (State Change Notification - Maintenance)

Algorithms

•

Information: D1-COMMINFO (Communication Information)

•

Pre-Processing: D3-SETDFBOEC (Set Default BO elements - Connect/Disconnect Notification)

Lifecycle / Algorithms

Note: Does not include "Transition to Default Next Status" monitor algorithms.

•

Pending

•

Validate

•

Enter: D3-FPCBORC (Find Parent Communication BO Remote Connect)

•

Enter: D1-VALCOMTP (Validate Communication Type)

•

Enter: D3-VSCC (Validate State Change Code)

•

Validation Error

•

Monitor: D1-RBOE (Rety BO in Error)

•

Enter: D1-CTDEBOE (Create To Do Entry for BO in Error)

•

Exit: D1-GTDCBO (Generic To Do Completion for BOs)

•

Discarded

•

Enter: D3-FAILPCOUT (Fail Parent Outbound Communication)

•

Create Completion Event

•

D3-CCE (Create Completion Event)

•

Completed

•

Enter: D3-UPCMEVDTR (Update Parent Communication’s Event Date Time Connect)

•

Enter: D3-TRANPRBO (Transition Parent Outbound Communication BO)

XAI Inbound Services

You must also create an XAI Inbound Service for each type of message to be received from an external system. XAI inbound systems define the details of how messages are received from an external system, including the inbound communication business object (or business service or service script) to be invoked when the response message is received. As in the case of inbound communication business objects, the set of XAI inbound services you need to create is based on the types of messages the system is designed to send. To continue the example above, you might create the following XAI inbound services:

XAI Inbound Service

Schema

(Inbound Communication Business Object)

Commission Device Response

Commission Device Response

Decommission Device Response

Decommission Device Response

Device Status Check Response

Device Status Check Response

On-Demand Read Response

On-Demand Read Response

Connect Device Response

Remote Connect Response

Disconnect Device Response

Remote Disconnect Response

Refer to the Oracle Utilities Application Framework documentation for more information about XAI Inbound Services.

Create Service Provider for Head-End System

Each head-end system that communicates with Oracle Utilities Smart Grid Gateway should be defined as a service provider. The service provider’s processing roles and methods are used by many processes to determine the specific manner in which data is to be sent or received from the service provider. For example, the "Remote Connect" processing role defines the specific type of outbound communication business object to use when sending outbound communications to the head-end system as a result of a remote connect command.

The Landis+Gyr service provider provided with the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr uses the following processing methods:

Processing Role

Processing Method

On-Demand Read (Scalar) (D1SC)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to Landis+Gyr as a result of an on-demand read (scalar) command. (D3-InitiateMRByMtrNbr / Initiate Meter Read By Meter Number (CMD3))

Remote Connect (D1RC)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to Landis+Gyr as a result of a remote connect command. (D3-InitiateConnectDisconnect / Connect Device (D3-CONNECT))

Remote Disconnect (D1RD)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to Landis+Gyr as a result of a remote connect command. (D3-InitiateConnectDisconnect / Disconnect Device (D3-DISCONNEC))

Note: The table above only lists processing methods used in processing commands.

Command processing methods can define a default outbound communication business object/outbound message type, or can specify an outbound communication business object/outbound message type for each Device Type.

Other processing roles and methods used in processing commands are described below

Processing Role

Processing Method

Device Commission (D1DC)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of a commission device command.

Device Decommission (D1DD)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of a decommission device command.

Device Status Check (D1DS)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of a device status check command.

On-Demand Read (Interval) (D1IN)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of an on-demand read (interval) command.

See Service Providers In Detail and Processing Methods In Detail for more information about service providers and processing methods.

Adapters for Issuing and Initiating Commands

This section outlines the steps involved in creating an adapter to support initiating commands and communications between Oracle Utilities Smart Grid Gateway and a head-end system. These steps include:

•

Configure Outbound Communication

•

Configure Middleware

•

Configure Inbound Communication

•

Create Service Provider for Head-End System

•

Creating Custom Commands

Configure Outbound Communication

Outbound Communications represent messages sent from Oracle Utilities Smart Grid Gateway to the head-end system or edge application (such as Oracle Customer Care and Billing). Outbound communications use the following types of objects:

•

Outbound Communication Business Objects

•

Outbound Message Types

•

XAI Senders

•

External Systems

Outbound Communication Business Objects

Outbound communication business object must be created for each type of message to be sent to the head-end system. This is based on the types of messages the system is designed to accept. For example, suppose a head-end system supports the following types of commands: device commission, device decommission, device status check, on-demand readings, remote connect, and remote disconnect, and that this head-end system accepts a separate type of message for each command. For this example, you would need to create outbound communication business objects for each command, as follows:

Command

Outbound Communication Business Object

Commission Device

Commission Device Outbound Communication

Decommission Device

Decommission Device Outbound Communication

Device Status Check

Device Status Check Outbound Communication

On-Demand Read

On-Demand Read Outbound Communication

Remote Connect

Remote Connect Outbound Communication

Remote Disconnect

Remote Disconnect Outbound Communication

The specifics of each business object are based on the type of message to be sent to the head-end system. The table below provides an example of the "Initiate Connect Disconnect" outbound communication business object used by the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr.

Option

Description

Business Object

D3-InitiateConnectDisconnect

Description

Initiate Connect Disconnect

Maintenance Object

D1-COMMOUT (Communication Out)

Application Service

D3-INITIATECONDISCON (Initiate Connect Disconnect)

Instance Control

Allow New Instances

Options

•

Related Administration BO: D3-InitiateConnectDisconType (Initiate Connect Disconnect Type)

•

Display UI Map: D3-InitConDisconMltSpkDisplay (Initiate Connect Disconnect Display)

•

Portal Navigation Option: d1OBCommunicationNavOpt (Outbound Communication Navigation Option)

•

Display Map Service Script: D3-RtICDDtls (Connect Disconnect - Retrieve Details for Display)

•

Maintenance Map UI Map: D3-InitConDisconMltSpkMaint (Connect Disconnect Maintenance)

Algorithms

•

Information: D1-COMMINFO (Communication Information)

•

Pre-Processing: D3-GDRFFPA (Default required fields from Parent Activity)

•

Pre-Processing: D3-DLAC (Default Load Action Check)

Lifecycle / Algorithms

Note: Does not include "Transition to Default Next Status" monitor algorithms.

•

Pending

•

Validate

•

Enter: D1-VALCOMTP (Validate Communication Type)

•

Validation Error

•

Monitor: D1-RBOE (Rety BO in Error)

•

Enter: D1-CTDEBOE (Create To Do Entry for BO in Error)

•

Exit: D1-GTDCBO (Generic To Do Completion for BOs)

•

Awaiting Response

•

Monitor: D1-TIMEOUT (Time Out)

•

Enter: D3-PICDSD (Populate Initial Connect Disconnect Send Detail)

•

Enter: D3-CCDOBTMSG (Create Connect/Disconnect Out Bound Message)

•

Retry

•

Response Error

•

Same as Validation Error (above)

•

Discarded

•

Enter: D1-TPATOF (Transition Parent Activity to Failed)

•

Completed

•

Enter: D3-UCCDFTPA (Update Connect Disconnect Completion Flag And Transition Parent Activity)

Outbound Message Types

A outbound message type must also be created for each type of message to be sent to the head-end system. Again, this is based on the types of messages the head-end system is designed to accept. To continue the example above, you might create the following outbound message types:

Command

Outbound Message Type

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read

On-Demand Read

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about outbound message types.

XAI Senders

You must also create an XAI Sender for each type of message to be sent to an external system. XAI senders define the details of how messages are sent to an external system. As in the case of outbound communication business objects and outbound message types, the set of XAI senders you need to create is based on the types of messages the head-end system is designed to accept. To continue the example above, you might create the following XAI senders:

Command

XAI Sender

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read

On-Demand Read

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about XAI senders.

External Systems

You must also create an External System for each external system to which Oracle Utilities Smart Grid Gateway will send messages. Each external system defines a set of outbound message types that will be sent to that system. The external system also specifies the following for each outbound message type:

•

The outbound message type

•

The processing method used to send the message (Batch, XAI, or Real-time)

•

The corresponding XAI senders

•

Batch Control (if Processing Method is set to Batch)

•

Message XSL, W3C Schema, and Response XSL (as applicable)

To continue the example above, you might create the following external system:

Head-End System

Outbound Message Type

Processing Method

XAI Sender

Message XSL /Response XSL

Commission Device

Real-time

Commission Device

HES-Request.xsl /

HES-Response.xsl

Decommission Device

Real-time

Decommission Device

HES-Request.xsl /

HES-Response.xsl

Device Status Check

Real-time

Device Status Check

HES-Request.xsl /

HES-Response.xsl

On-Demand Read

Real-time

On-Demand Read

HES-Request.xsl /

HES-Response.xsl

Remote Connect

Real-time

Connect Device

HES-Request.xsl /

HES-Response.xsl

Remote Disconnect

Real-time

Disconnect Device

HES-Request.xsl /

HES-Response.xsl

Refer to the Oracle Utilities Application Framework documentation for more information about external systems.

Configure Middleware

Middleware is used to facilitate communication between the head-end system and Oracle Utilities Smart Grid Gateway. In the case of processing commands, the middleware performs the following steps:

•

Accepts outbound messages from XAI Senders

The middleware must monitor the XAI senders configured to send messages from Oracle Utilities Smart Grid Gateway to the head-end system.

•

Transforms communications from SGG format into head-end system format

Messages are sent in a standard format used by Oracle Utilities Smart Grid Gateway. The middleware must transform each message from this standard format into the format used by the head-end system.

•

Sends messages to the head-end system

The middleware must then send the transformed message to the head-end system. In Oracle Utilities Smart Grid Gateway adapters, this is done via a web service call to web services defined for the head-end system.

•

Receives responses from the head-end system

The middleware also receives responses from the head-end system that indicate if the command was successfully carried out.

•

Transforms communications from head-end system format into SGG format

Response messages are sent in a format used by the head-end system. The middleware must transform each message from this format into the standard format used by Oracle Utilities Smart Grid Gateway.

•

Sends response message to Oracle Utilities Smart Grid Gateway by invoking an XAI Inbound Service

The middleware then sends the response message to the application. This can be done via web service call to an XAI Inbound Service or by depositing the message in a JMS queue.

Oracle Utilities Smart Grid Gateway adapters use Oracle Business Process Exeecution Language (BPEL) to perform these operations. Refer to the following documentation for more details concerning the specific configurations of BPEL used by Oracle Utilities Smart Gird Gateway adapters for processing commands:

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr Configuration Guide

Pre-configured BPEL processes can be extended to support custom requirements during message processing.

Configure Inbound Communication

Inbound Communications represent messages sent from a head-end system or edge application (such as Oracle Customer Care and Billing) to Oracle Utilities Smart Grid Gateway. Inbound communications are typically sent in response to a command. Inbound communications use the following types of objects:

•

Inbound Communication Business Objects

•

XAI Inbound Services

Inbound Communication Business Objects

An inbound communication business object must be created for each type of message to be received from the head-end systems, based on the types of messages the system is designed to send. To continue the above example, a head-end system that supports the types of commands outlined above (device commission, device decommission, device status check, on-demand readings, remote connect, and remote disconnect) might send a separate type of message in response to each command. For this example, you would need to create the following inbound communication business objects:

Command Being Responded To

Inbound Communication Business Object

Commission Device

Commission Device Response

Decommission Device

Decommission Device Response

Device Status Check

Device Status Check Response

On-Demand Read

On-Demand Read Response

Remote Connect

Remote Connect Response

Remote Disconnect

Remote Disconnect Response

The specifics of each business object are based on the type of message to be sent to the head-end system. The table below provides an example of the "Connect Disconnect State Changed Notification (Multispeak)" inbound communication business object used by the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr.

Option

Description

Business Object

D3-ConnectDisconStateChgNtf

Description

Connect Disconnect State Changed Notification (Multispeak)

Maintenance Object

D1-COMMIN (Communication In)

Application Service

D3-CONDISSTCHGNTBOAS (State Change Notification BO)

Instance Control

Allow New Instances

Options

•

Related Administration BO: D3-ConnectDisconStateChgNtfTyp (Connect Disconnect State Change Notify Type)

•

Display UI Map: D3-ConDisconStChgMltSpkDisplay (State Change Notification - Display)

•

Portal Navigation Option: d1IBCommunicationNavOpt (Inbound Communication Navigation Option)

•

Display Map Service Script: D3-RtSCNDtls (State Change - Retrieve Details for Display)

•

Maintenance Map UI Map: D3-ConDisconStChgMltSpkMaint (State Change Notification - Maintenance)

Algorithms

•

Information: D1-COMMINFO (Communication Information)

•

Pre-Processing: D3-SETDFBOEC (Set Default BO elements - Connect/Disconnect Notification)

Lifecycle / Algorithms

Note: Does not include "Transition to Default Next Status" monitor algorithms.

•

Pending

•

Validate

•

Enter: D3-FPCBORC (Find Parent Communication BO Remote Connect)

•

Enter: D1-VALCOMTP (Validate Communication Type)

•

Enter: D3-VSCC (Validate State Change Code)

•

Validation Error

•

Monitor: D1-RBOE (Rety BO in Error)

•

Enter: D1-CTDEBOE (Create To Do Entry for BO in Error)

•

Exit: D1-GTDCBO (Generic To Do Completion for BOs)

•

Discarded

•

Enter: D3-FAILPCOUT (Fail Parent Outbound Communication)

•

Create Completion Event

•

D3-CCE (Create Completion Event)

•

Completed

•

Enter: D3-UPCMEVDTR (Update Parent Communication’s Event Date Time Connect)

•

Enter: D3-TRANPRBO (Transition Parent Outbound Communication BO)

XAI Inbound Services

You must also create an XAI Inbound Service for each type of message to be received from an external system. XAI inbound systems define the details of how messages are received from an external system, including the inbound communication business object (or business service or service script) to be invoked when the response message is received. As in the case of inbound communication business objects, the set of XAI inbound services you need to create is based on the types of messages the system is designed to send. To continue the example above, you might create the following XAI inbound services:

XAI Inbound Service

Schema

(Inbound Communication Business Object)

Commission Device Response

Commission Device Response

Decommission Device Response

Decommission Device Response

Device Status Check Response

Device Status Check Response

On-Demand Read Response

On-Demand Read Response

Connect Device Response

Remote Connect Response

Disconnect Device Response

Remote Disconnect Response

Refer to the Oracle Utilities Application Framework documentation for more information about XAI Inbound Services.

Create Service Provider for Head-End System

Each head-end system that communicates with Oracle Utilities Smart Grid Gateway should be defined as a service provider. The service provider’s processing roles and methods are used by many processes to determine the specific manner in which data is to be sent or received from the service provider. For example, the "Remote Connect" processing role defines the specific type of outbound communication business object to use when sending outbound communications to the head-end system as a result of a remote connect command.

The Landis+Gyr service provider provided with the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr uses the following processing methods:

Processing Role

Processing Method

On-Demand Read (Scalar) (D1SC)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to Landis+Gyr as a result of an on-demand read (scalar) command. (D3-InitiateMRByMtrNbr / Initiate Meter Read By Meter Number (CMD3))

Remote Connect (D1RC)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to Landis+Gyr as a result of a remote connect command. (D3-InitiateConnectDisconnect / Connect Device (D3-CONNECT))

Remote Disconnect (D1RD)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to Landis+Gyr as a result of a remote connect command. (D3-InitiateConnectDisconnect / Disconnect Device (D3-DISCONNEC))

Note: The table above only lists processing methods used in processing commands.

Command processing methods can define a default outbound communication business object/outbound message type, or can specify an outbound communication business object/outbound message type for each Device Type.

Other processing roles and methods used in processing commands are described below

Processing Role

Processing Method

Device Commission (D1DC)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of a commission device command.

Device Decommission (D1DD)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of a decommission device command.

Device Status Check (D1DS)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of a device status check command.

On-Demand Read (Interval) (D1IN)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of an on-demand read (interval) command.

See Service Providers In Detail and Processing Methods In Detail for more information about service providers and processing methods.

Adapters for Issuing and Initiating Commands

This section outlines the steps involved in creating an adapter to support initiating commands and communications between Oracle Utilities Smart Grid Gateway and a head-end system. These steps include:

•

Configure Outbound Communication

•

Configure Middleware

•

Configure Inbound Communication

•

Create Service Provider for Head-End System

•

Creating Custom Commands

Configure Outbound Communication

Outbound Communications represent messages sent from Oracle Utilities Smart Grid Gateway to the head-end system or edge application (such as Oracle Customer Care and Billing). Outbound communications use the following types of objects:

•

Outbound Communication Business Objects

•

Outbound Message Types

•

XAI Senders

•

External Systems

Outbound Communication Business Objects

Outbound communication business object must be created for each type of message to be sent to the head-end system. This is based on the types of messages the system is designed to accept. For example, suppose a head-end system supports the following types of commands: device commission, device decommission, device status check, on-demand readings, remote connect, and remote disconnect, and that this head-end system accepts a separate type of message for each command. For this example, you would need to create outbound communication business objects for each command, as follows:

Command

Outbound Communication Business Object

Commission Device

Commission Device Outbound Communication

Decommission Device

Decommission Device Outbound Communication

Device Status Check

Device Status Check Outbound Communication

On-Demand Read

On-Demand Read Outbound Communication

Remote Connect

Remote Connect Outbound Communication

Remote Disconnect

Remote Disconnect Outbound Communication

The specifics of each business object are based on the type of message to be sent to the head-end system. The table below provides an example of the "Initiate Connect Disconnect" outbound communication business object used by the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr.

Option

Description

Business Object

D3-InitiateConnectDisconnect

Description

Initiate Connect Disconnect

Maintenance Object

D1-COMMOUT (Communication Out)

Application Service

D3-INITIATECONDISCON (Initiate Connect Disconnect)

Instance Control

Allow New Instances

Options

•

Related Administration BO: D3-InitiateConnectDisconType (Initiate Connect Disconnect Type)

•

Display UI Map: D3-InitConDisconMltSpkDisplay (Initiate Connect Disconnect Display)

•

Portal Navigation Option: d1OBCommunicationNavOpt (Outbound Communication Navigation Option)

•

Display Map Service Script: D3-RtICDDtls (Connect Disconnect - Retrieve Details for Display)

•

Maintenance Map UI Map: D3-InitConDisconMltSpkMaint (Connect Disconnect Maintenance)

Algorithms

•

Information: D1-COMMINFO (Communication Information)

•

Pre-Processing: D3-GDRFFPA (Default required fields from Parent Activity)

•

Pre-Processing: D3-DLAC (Default Load Action Check)

Lifecycle / Algorithms

Note: Does not include "Transition to Default Next Status" monitor algorithms.

•

Pending

•

Validate

•

Enter: D1-VALCOMTP (Validate Communication Type)

•

Validation Error

•

Monitor: D1-RBOE (Rety BO in Error)

•

Enter: D1-CTDEBOE (Create To Do Entry for BO in Error)

•

Exit: D1-GTDCBO (Generic To Do Completion for BOs)

•

Awaiting Response

•

Monitor: D1-TIMEOUT (Time Out)

•

Enter: D3-PICDSD (Populate Initial Connect Disconnect Send Detail)

•

Enter: D3-CCDOBTMSG (Create Connect/Disconnect Out Bound Message)

•

Retry

•

Response Error

•

Same as Validation Error (above)

•

Discarded

•

Enter: D1-TPATOF (Transition Parent Activity to Failed)

•

Completed

•

Enter: D3-UCCDFTPA (Update Connect Disconnect Completion Flag And Transition Parent Activity)

Outbound Message Types

A outbound message type must also be created for each type of message to be sent to the head-end system. Again, this is based on the types of messages the head-end system is designed to accept. To continue the example above, you might create the following outbound message types:

Command

Outbound Message Type

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read

On-Demand Read

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about outbound message types.

XAI Senders

You must also create an XAI Sender for each type of message to be sent to an external system. XAI senders define the details of how messages are sent to an external system. As in the case of outbound communication business objects and outbound message types, the set of XAI senders you need to create is based on the types of messages the head-end system is designed to accept. To continue the example above, you might create the following XAI senders:

Command

XAI Sender

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read

On-Demand Read

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about XAI senders.

External Systems

You must also create an External System for each external system to which Oracle Utilities Smart Grid Gateway will send messages. Each external system defines a set of outbound message types that will be sent to that system. The external system also specifies the following for each outbound message type:

•

The outbound message type

•

The processing method used to send the message (Batch, XAI, or Real-time)

•

The corresponding XAI senders

•

Batch Control (if Processing Method is set to Batch)

•

Message XSL, W3C Schema, and Response XSL (as applicable)

To continue the example above, you might create the following external system:

Head-End System

Outbound Message Type

Processing Method

XAI Sender

Message XSL /Response XSL

Commission Device

Real-time

Commission Device

HES-Request.xsl /

HES-Response.xsl

Decommission Device

Real-time

Decommission Device

HES-Request.xsl /

HES-Response.xsl

Device Status Check

Real-time

Device Status Check

HES-Request.xsl /

HES-Response.xsl

On-Demand Read

Real-time

On-Demand Read

HES-Request.xsl /

HES-Response.xsl

Remote Connect

Real-time

Connect Device

HES-Request.xsl /

HES-Response.xsl

Remote Disconnect

Real-time

Disconnect Device

HES-Request.xsl /

HES-Response.xsl

Refer to the Oracle Utilities Application Framework documentation for more information about external systems.

Configure Middleware

Middleware is used to facilitate communication between the head-end system and Oracle Utilities Smart Grid Gateway. In the case of processing commands, the middleware performs the following steps:

•

Accepts outbound messages from XAI Senders

The middleware must monitor the XAI senders configured to send messages from Oracle Utilities Smart Grid Gateway to the head-end system.

•

Transforms communications from SGG format into head-end system format

Messages are sent in a standard format used by Oracle Utilities Smart Grid Gateway. The middleware must transform each message from this standard format into the format used by the head-end system.

•

Sends messages to the head-end system

The middleware must then send the transformed message to the head-end system. In Oracle Utilities Smart Grid Gateway adapters, this is done via a web service call to web services defined for the head-end system.

•

Receives responses from the head-end system

The middleware also receives responses from the head-end system that indicate if the command was successfully carried out.

•

Transforms communications from head-end system format into SGG format

Response messages are sent in a format used by the head-end system. The middleware must transform each message from this format into the standard format used by Oracle Utilities Smart Grid Gateway.

•

Sends response message to Oracle Utilities Smart Grid Gateway by invoking an XAI Inbound Service

The middleware then sends the response message to the application. This can be done via web service call to an XAI Inbound Service or by depositing the message in a JMS queue.

Oracle Utilities Smart Grid Gateway adapters use Oracle Business Process Exeecution Language (BPEL) to perform these operations. Refer to the following documentation for more details concerning the specific configurations of BPEL used by Oracle Utilities Smart Gird Gateway adapters for processing commands:

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr Configuration Guide

Pre-configured BPEL processes can be extended to support custom requirements during message processing.

Configure Inbound Communication

Inbound Communications represent messages sent from a head-end system or edge application (such as Oracle Customer Care and Billing) to Oracle Utilities Smart Grid Gateway. Inbound communications are typically sent in response to a command. Inbound communications use the following types of objects:

•

Inbound Communication Business Objects

•

XAI Inbound Services

Inbound Communication Business Objects

An inbound communication business object must be created for each type of message to be received from the head-end systems, based on the types of messages the system is designed to send. To continue the above example, a head-end system that supports the types of commands outlined above (device commission, device decommission, device status check, on-demand readings, remote connect, and remote disconnect) might send a separate type of message in response to each command. For this example, you would need to create the following inbound communication business objects:

Command Being Responded To

Inbound Communication Business Object

Commission Device

Commission Device Response

Decommission Device

Decommission Device Response

Device Status Check

Device Status Check Response

On-Demand Read

On-Demand Read Response

Remote Connect

Remote Connect Response

Remote Disconnect

Remote Disconnect Response

The specifics of each business object are based on the type of message to be sent to the head-end system. The table below provides an example of the "Connect Disconnect State Changed Notification (Multispeak)" inbound communication business object used by the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr.

Option

Description

Business Object

D3-ConnectDisconStateChgNtf

Description

Connect Disconnect State Changed Notification (Multispeak)

Maintenance Object

D1-COMMIN (Communication In)

Application Service

D3-CONDISSTCHGNTBOAS (State Change Notification BO)

Instance Control

Allow New Instances

Options

•

Related Administration BO: D3-ConnectDisconStateChgNtfTyp (Connect Disconnect State Change Notify Type)

•

Display UI Map: D3-ConDisconStChgMltSpkDisplay (State Change Notification - Display)

•

Portal Navigation Option: d1IBCommunicationNavOpt (Inbound Communication Navigation Option)

•

Display Map Service Script: D3-RtSCNDtls (State Change - Retrieve Details for Display)

•

Maintenance Map UI Map: D3-ConDisconStChgMltSpkMaint (State Change Notification - Maintenance)

Algorithms

•

Information: D1-COMMINFO (Communication Information)

•

Pre-Processing: D3-SETDFBOEC (Set Default BO elements - Connect/Disconnect Notification)

Lifecycle / Algorithms

Note: Does not include "Transition to Default Next Status" monitor algorithms.

•

Pending

•

Validate

•

Enter: D3-FPCBORC (Find Parent Communication BO Remote Connect)

•

Enter: D1-VALCOMTP (Validate Communication Type)

•

Enter: D3-VSCC (Validate State Change Code)

•

Validation Error

•

Monitor: D1-RBOE (Rety BO in Error)

•

Enter: D1-CTDEBOE (Create To Do Entry for BO in Error)

•

Exit: D1-GTDCBO (Generic To Do Completion for BOs)

•

Discarded

•

Enter: D3-FAILPCOUT (Fail Parent Outbound Communication)

•

Create Completion Event

•

D3-CCE (Create Completion Event)

•

Completed

•

Enter: D3-UPCMEVDTR (Update Parent Communication’s Event Date Time Connect)

•

Enter: D3-TRANPRBO (Transition Parent Outbound Communication BO)

XAI Inbound Services

You must also create an XAI Inbound Service for each type of message to be received from an external system. XAI inbound systems define the details of how messages are received from an external system, including the inbound communication business object (or business service or service script) to be invoked when the response message is received. As in the case of inbound communication business objects, the set of XAI inbound services you need to create is based on the types of messages the system is designed to send. To continue the example above, you might create the following XAI inbound services:

XAI Inbound Service

Schema

(Inbound Communication Business Object)

Commission Device Response

Commission Device Response

Decommission Device Response

Decommission Device Response

Device Status Check Response

Device Status Check Response

On-Demand Read Response

On-Demand Read Response

Connect Device Response

Remote Connect Response

Disconnect Device Response

Remote Disconnect Response

Refer to the Oracle Utilities Application Framework documentation for more information about XAI Inbound Services.

Create Service Provider for Head-End System

Each head-end system that communicates with Oracle Utilities Smart Grid Gateway should be defined as a service provider. The service provider’s processing roles and methods are used by many processes to determine the specific manner in which data is to be sent or received from the service provider. For example, the "Remote Connect" processing role defines the specific type of outbound communication business object to use when sending outbound communications to the head-end system as a result of a remote connect command.

The Landis+Gyr service provider provided with the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr uses the following processing methods:

Processing Role

Processing Method

On-Demand Read (Scalar) (D1SC)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to Landis+Gyr as a result of an on-demand read (scalar) command. (D3-InitiateMRByMtrNbr / Initiate Meter Read By Meter Number (CMD3))

Remote Connect (D1RC)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to Landis+Gyr as a result of a remote connect command. (D3-InitiateConnectDisconnect / Connect Device (D3-CONNECT))

Remote Disconnect (D1RD)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to Landis+Gyr as a result of a remote connect command. (D3-InitiateConnectDisconnect / Disconnect Device (D3-DISCONNEC))

Note: The table above only lists processing methods used in processing commands.

Command processing methods can define a default outbound communication business object/outbound message type, or can specify an outbound communication business object/outbound message type for each Device Type.

Other processing roles and methods used in processing commands are described below

Processing Role

Processing Method

Device Commission (D1DC)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of a commission device command.

Device Decommission (D1DD)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of a decommission device command.

Device Status Check (D1DS)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of a device status check command.

On-Demand Read (Interval) (D1IN)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of an on-demand read (interval) command.

See Service Providers In Detail and Processing Methods In Detail for more information about service providers and processing methods.

Adapters for Issuing and Initiating Commands

This section outlines the steps involved in creating an adapter to support initiating commands and communications between Oracle Utilities Smart Grid Gateway and a head-end system. These steps include:

•

Configure Outbound Communication

•

Configure Middleware

•

Configure Inbound Communication

•

Create Service Provider for Head-End System

•

Creating Custom Commands

Configure Outbound Communication

Outbound Communications represent messages sent from Oracle Utilities Smart Grid Gateway to the head-end system or edge application (such as Oracle Customer Care and Billing). Outbound communications use the following types of objects:

•

Outbound Communication Business Objects

•

Outbound Message Types

•

XAI Senders

•

External Systems

Outbound Communication Business Objects

Outbound communication business object must be created for each type of message to be sent to the head-end system. This is based on the types of messages the system is designed to accept. For example, suppose a head-end system supports the following types of commands: device commission, device decommission, device status check, on-demand readings, remote connect, and remote disconnect, and that this head-end system accepts a separate type of message for each command. For this example, you would need to create outbound communication business objects for each command, as follows:

Command

Outbound Communication Business Object

Commission Device

Commission Device Outbound Communication

Decommission Device

Decommission Device Outbound Communication

Device Status Check

Device Status Check Outbound Communication

On-Demand Read

On-Demand Read Outbound Communication

Remote Connect

Remote Connect Outbound Communication

Remote Disconnect

Remote Disconnect Outbound Communication

The specifics of each business object are based on the type of message to be sent to the head-end system. The table below provides an example of the "Initiate Connect Disconnect" outbound communication business object used by the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr.

Option

Description

Business Object

D3-InitiateConnectDisconnect

Description

Initiate Connect Disconnect

Maintenance Object

D1-COMMOUT (Communication Out)

Application Service

D3-INITIATECONDISCON (Initiate Connect Disconnect)

Instance Control

Allow New Instances

Options

•

Related Administration BO: D3-InitiateConnectDisconType (Initiate Connect Disconnect Type)

•

Display UI Map: D3-InitConDisconMltSpkDisplay (Initiate Connect Disconnect Display)

•

Portal Navigation Option: d1OBCommunicationNavOpt (Outbound Communication Navigation Option)

•

Display Map Service Script: D3-RtICDDtls (Connect Disconnect - Retrieve Details for Display)

•

Maintenance Map UI Map: D3-InitConDisconMltSpkMaint (Connect Disconnect Maintenance)

Algorithms

•

Information: D1-COMMINFO (Communication Information)

•

Pre-Processing: D3-GDRFFPA (Default required fields from Parent Activity)

•

Pre-Processing: D3-DLAC (Default Load Action Check)

Lifecycle / Algorithms

Note: Does not include "Transition to Default Next Status" monitor algorithms.

•

Pending

•

Validate

•

Enter: D1-VALCOMTP (Validate Communication Type)

•

Validation Error

•

Monitor: D1-RBOE (Rety BO in Error)

•

Enter: D1-CTDEBOE (Create To Do Entry for BO in Error)

•

Exit: D1-GTDCBO (Generic To Do Completion for BOs)

•

Awaiting Response

•

Monitor: D1-TIMEOUT (Time Out)

•

Enter: D3-PICDSD (Populate Initial Connect Disconnect Send Detail)

•

Enter: D3-CCDOBTMSG (Create Connect/Disconnect Out Bound Message)

•

Retry

•

Response Error

•

Same as Validation Error (above)

•

Discarded

•

Enter: D1-TPATOF (Transition Parent Activity to Failed)

•

Completed

•

Enter: D3-UCCDFTPA (Update Connect Disconnect Completion Flag And Transition Parent Activity)

Outbound Message Types

A outbound message type must also be created for each type of message to be sent to the head-end system. Again, this is based on the types of messages the head-end system is designed to accept. To continue the example above, you might create the following outbound message types:

Command

Outbound Message Type

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read

On-Demand Read

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about outbound message types.

XAI Senders

You must also create an XAI Sender for each type of message to be sent to an external system. XAI senders define the details of how messages are sent to an external system. As in the case of outbound communication business objects and outbound message types, the set of XAI senders you need to create is based on the types of messages the head-end system is designed to accept. To continue the example above, you might create the following XAI senders:

Command

XAI Sender

Commission Device

Commission Device

Decommission Device

Decommission Device

Device Status Check

Device Status Check

On-Demand Read

On-Demand Read

Remote Connect

Connect Device

Remote Disconnect

Disconnect Device

Refer to the Oracle Utilities Application Framework documentation for more information about XAI senders.

External Systems

You must also create an External System for each external system to which Oracle Utilities Smart Grid Gateway will send messages. Each external system defines a set of outbound message types that will be sent to that system. The external system also specifies the following for each outbound message type:

•

The outbound message type

•

The processing method used to send the message (Batch, XAI, or Real-time)

•

The corresponding XAI senders

•

Batch Control (if Processing Method is set to Batch)

•

Message XSL, W3C Schema, and Response XSL (as applicable)

To continue the example above, you might create the following external system:

Head-End System

Outbound Message Type

Processing Method

XAI Sender

Message XSL /Response XSL

Commission Device

Real-time

Commission Device

HES-Request.xsl /

HES-Response.xsl

Decommission Device

Real-time

Decommission Device

HES-Request.xsl /

HES-Response.xsl

Device Status Check

Real-time

Device Status Check

HES-Request.xsl /

HES-Response.xsl

On-Demand Read

Real-time

On-Demand Read

HES-Request.xsl /

HES-Response.xsl

Remote Connect

Real-time

Connect Device

HES-Request.xsl /

HES-Response.xsl

Remote Disconnect

Real-time

Disconnect Device

HES-Request.xsl /

HES-Response.xsl

Refer to the Oracle Utilities Application Framework documentation for more information about external systems.

Configure Middleware

Middleware is used to facilitate communication between the head-end system and Oracle Utilities Smart Grid Gateway. In the case of processing commands, the middleware performs the following steps:

•

Accepts outbound messages from XAI Senders

The middleware must monitor the XAI senders configured to send messages from Oracle Utilities Smart Grid Gateway to the head-end system.

•

Transforms communications from SGG format into head-end system format

Messages are sent in a standard format used by Oracle Utilities Smart Grid Gateway. The middleware must transform each message from this standard format into the format used by the head-end system.

•

Sends messages to the head-end system

The middleware must then send the transformed message to the head-end system. In Oracle Utilities Smart Grid Gateway adapters, this is done via a web service call to web services defined for the head-end system.

•

Receives responses from the head-end system

The middleware also receives responses from the head-end system that indicate if the command was successfully carried out.

•

Transforms communications from head-end system format into SGG format

Response messages are sent in a format used by the head-end system. The middleware must transform each message from this format into the standard format used by Oracle Utilities Smart Grid Gateway.

•

Sends response message to Oracle Utilities Smart Grid Gateway by invoking an XAI Inbound Service

The middleware then sends the response message to the application. This can be done via web service call to an XAI Inbound Service or by depositing the message in a JMS queue.

Oracle Utilities Smart Grid Gateway adapters use Oracle Business Process Exeecution Language (BPEL) to perform these operations. Refer to the following documentation for more details concerning the specific configurations of BPEL used by Oracle Utilities Smart Gird Gateway adapters for processing commands:

•

Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr Configuration Guide

Pre-configured BPEL processes can be extended to support custom requirements during message processing.

Configure Inbound Communication

Inbound Communications represent messages sent from a head-end system or edge application (such as Oracle Customer Care and Billing) to Oracle Utilities Smart Grid Gateway. Inbound communications are typically sent in response to a command. Inbound communications use the following types of objects:

•

Inbound Communication Business Objects

•

XAI Inbound Services

Inbound Communication Business Objects

An inbound communication business object must be created for each type of message to be received from the head-end systems, based on the types of messages the system is designed to send. To continue the above example, a head-end system that supports the types of commands outlined above (device commission, device decommission, device status check, on-demand readings, remote connect, and remote disconnect) might send a separate type of message in response to each command. For this example, you would need to create the following inbound communication business objects:

Command Being Responded To

Inbound Communication Business Object

Commission Device

Commission Device Response

Decommission Device

Decommission Device Response

Device Status Check

Device Status Check Response

On-Demand Read

On-Demand Read Response

Remote Connect

Remote Connect Response

Remote Disconnect

Remote Disconnect Response

The specifics of each business object are based on the type of message to be sent to the head-end system. The table below provides an example of the "Connect Disconnect State Changed Notification (Multispeak)" inbound communication business object used by the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr.

Option

Description

Business Object

D3-ConnectDisconStateChgNtf

Description

Connect Disconnect State Changed Notification (Multispeak)

Maintenance Object

D1-COMMIN (Communication In)

Application Service

D3-CONDISSTCHGNTBOAS (State Change Notification BO)

Instance Control

Allow New Instances

Options

•

Related Administration BO: D3-ConnectDisconStateChgNtfTyp (Connect Disconnect State Change Notify Type)

•

Display UI Map: D3-ConDisconStChgMltSpkDisplay (State Change Notification - Display)

•

Portal Navigation Option: d1IBCommunicationNavOpt (Inbound Communication Navigation Option)

•

Display Map Service Script: D3-RtSCNDtls (State Change - Retrieve Details for Display)

•

Maintenance Map UI Map: D3-ConDisconStChgMltSpkMaint (State Change Notification - Maintenance)

Algorithms

•

Information: D1-COMMINFO (Communication Information)

•

Pre-Processing: D3-SETDFBOEC (Set Default BO elements - Connect/Disconnect Notification)

Lifecycle / Algorithms

Note: Does not include "Transition to Default Next Status" monitor algorithms.

•

Pending

•

Validate

•

Enter: D3-FPCBORC (Find Parent Communication BO Remote Connect)

•

Enter: D1-VALCOMTP (Validate Communication Type)

•

Enter: D3-VSCC (Validate State Change Code)

•

Validation Error

•

Monitor: D1-RBOE (Rety BO in Error)

•

Enter: D1-CTDEBOE (Create To Do Entry for BO in Error)

•

Exit: D1-GTDCBO (Generic To Do Completion for BOs)

•

Discarded

•

Enter: D3-FAILPCOUT (Fail Parent Outbound Communication)

•

Create Completion Event

•

D3-CCE (Create Completion Event)

•

Completed

•

Enter: D3-UPCMEVDTR (Update Parent Communication’s Event Date Time Connect)

•

Enter: D3-TRANPRBO (Transition Parent Outbound Communication BO)

XAI Inbound Services

You must also create an XAI Inbound Service for each type of message to be received from an external system. XAI inbound systems define the details of how messages are received from an external system, including the inbound communication business object (or business service or service script) to be invoked when the response message is received. As in the case of inbound communication business objects, the set of XAI inbound services you need to create is based on the types of messages the system is designed to send. To continue the example above, you might create the following XAI inbound services:

XAI Inbound Service

Schema

(Inbound Communication Business Object)

Commission Device Response

Commission Device Response

Decommission Device Response

Decommission Device Response

Device Status Check Response

Device Status Check Response

On-Demand Read Response

On-Demand Read Response

Connect Device Response

Remote Connect Response

Disconnect Device Response

Remote Disconnect Response

Refer to the Oracle Utilities Application Framework documentation for more information about XAI Inbound Services.

Create Service Provider for Head-End System

Each head-end system that communicates with Oracle Utilities Smart Grid Gateway should be defined as a service provider. The service provider’s processing roles and methods are used by many processes to determine the specific manner in which data is to be sent or received from the service provider. For example, the "Remote Connect" processing role defines the specific type of outbound communication business object to use when sending outbound communications to the head-end system as a result of a remote connect command.

The Landis+Gyr service provider provided with the Oracle Utilities Smart Grid Gateway Adapter for Landis+Gyr uses the following processing methods:

Processing Role

Processing Method

On-Demand Read (Scalar) (D1SC)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to Landis+Gyr as a result of an on-demand read (scalar) command. (D3-InitiateMRByMtrNbr / Initiate Meter Read By Meter Number (CMD3))

Remote Connect (D1RC)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to Landis+Gyr as a result of a remote connect command. (D3-InitiateConnectDisconnect / Connect Device (D3-CONNECT))

Remote Disconnect (D1RD)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to Landis+Gyr as a result of a remote connect command. (D3-InitiateConnectDisconnect / Disconnect Device (D3-DISCONNEC))

Note: The table above only lists processing methods used in processing commands.

Command processing methods can define a default outbound communication business object/outbound message type, or can specify an outbound communication business object/outbound message type for each Device Type.

Other processing roles and methods used in processing commands are described below

Processing Role

Processing Method

Device Commission (D1DC)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of a commission device command.

Device Decommission (D1DD)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of a decommission device command.

Device Status Check (D1DS)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of a device status check command.

On-Demand Read (Interval) (D1IN)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of an on-demand read (interval) command.

See Service Providers In Detail and Processing Methods In Detail for more information about service providers and processing methods.

Creating Custom Commands

Oracle Utilities Smart Grid Gateway supports a number of commands, including:

•

Commission Device

•

Decommission Device

•

Device Status Check

•

On-Demand Read

•

Remote Connect

•

Remote Disconnect

However, most head-end systems provide additional commands beyond these. This section outlines the steps involved in creating custom commands, including:

•

Create Command (Activity) Business Objects

•

Create Processing Roles and Configure Processing Methods

•

Create Outbound and Inbound Communications

•

Configure Middleware to Support New Messages

Create Command (Activity) Business Objects

Each command available through Oracle Utilities Smart Grid Gateway is defined as an activity business object. For each custom command you wish to create, you must create an activity business object. The specifics of each business object are based on the type of command to be issuesd to the head-end system. The table below provides an example of the "Remote Connect" activity business object used by the Oracle Utilities Smart Grid Gateway.

Option

Description

Business Object

D1-RemoteConnect

Description

Remote Connect

Maintenance Object

D1-ACTIVITY (Activity)

Application Service

D1-REMOTECONNECTBOAS (Remote Connect BO)

Instance Control

Allow New Instances

Options

•

Applicable Processing Role: D1RC (Remote Connect)

•

Applicable Processing Role: D1SC (On-Demand Read - Scalar)

•

Applicable Processing Role: D1LC (Load Check)

•

Related Administration BO: D1-RemoteConnectType (Remote Connect Type)

•

Display UI Map: D1-RemoteConnectDisplay (Remote Connect - Display)

•

Portal Navigation Option: d1ActivityNavOpt (Activity Navigation Option)

•

Display Map Service Script: D1-RtRCDtls (Remote Connect - Retreive Details for Display)

•

Maintenance UI Map: D1-RemoteConnectMaint (Remote Connect - Maintenance)

Algorithms

•

Information: D1-CRAINFO (Command Request Activity Information)

•

Pre-Processing: D1-DETACTTYP (Determine Activity Type)

•

Pre-Processing: D1-DMRO (Default Measurement Requested Override)

•

Pre-Processing: D1-DDR (Determine Device and Recipient)

•

Validation: D1GINPVAL (Common Input Validation

•

Validation: D1-VALMDEST (Validate Measurement Destination)

•

Validation: D1-VALMREQO (Validate Measurement Requested Override)

Lifecycle

Note: Does not include "Transition to Default Next Status" monitor algorithms.

•

Pending

•

Validation

•

Enter: D1-VALACTTDI (Validate Actvity Type and Transition to Error State If Invalid)

•

Enter: D1-VALDVCNCD (Validate Device is not already Connected)

•

Enter: D1-VHCPODR (Validate Head-end’s Capability to perform On-Demand Read)

•

Enter: D1-VHCPCD (Validate Head-end’s Capability to perform Connect Disconnect)

•

Enter: D1-CECD (Check for existing future disconnects)

•

Validation Error

•

Monitor: D1-WTTMOUT (Wait Time Out)

•

Monitor: D1-RBOE (Rety BO in Error)

•

Enter: D1-CTDEBOE (Create To Do Entry for BO in Error)

•

Exit: D1-GTDCBO (Generic To Do Completion for BOs)

•

Waiting for Effective Date

•

Monitor: D1-WAITEFFDT (Wait for Effective Date)

•

Enter: D1-RRER (Send Received Response to External Requester)

•

Connection Ready

•

Enter: D1-CLCOC (Create Load Check Outbound Communication)

•

Enter: D1-CODROC (Create On-Demand Read for Start Measurement)

•

Enter: D1-CRCOC (Create Remote Connect Outbound Communication)

Lifecycle (continued)

Note: Does not include "Transition to Default Next Status" monitor algorithms.

•

Communication in Progress

•

Communication Error

•

Same as Validation Error (above)

•

Retry

•

Enter: D1-COOC (Cancel Outstanding Outbound Communication)

•

Execute Completion Events

•

Enter: D1-EXCMPEVTS (Execute Completion Events)

•

Completion Events Error

•

Same as Validation Error (above)

•

Waiting for Measurement

•

Monitor: D1-RMVCE (Retrieve Measurements via Completion Events)

•

Monitor: D1-RFINSC (Retrieve Scalar Final Measurements)

•

Monitor: D1-RSINIMS (Retrieve Scalar Initial Measurements)

•

Monitor: D1-WFMTO (Wait for Measurement Time Out)

•

Wait Expired

•

Same as Validation Error (above)

•

Completed

•

Enter: D1-SRCNTEA (Send Remote Connect Notification to Edge Application)

•

Enter: D1-SODRTEA (Send Start Measurement to Edge Application)

•

Discarded

•

Enter: D1-COOC (Cancel Outstanding Outbound Communication)

•

Enter: D1-COCE (Cancel Outstanding Completion Events)

•

Enter: D1-FAILPA (Fail Parent Activity)

•

Enter: D1-FRER (Sesnd Fail Response to External Requester)

Create Processing Roles and Configure Processing Methods

After the command activity business object has been created, you must also create a processing role for the command, and associate to your activity business object and the appropriate processing method business object, and then add the processing role/method for the command to the service provider that represents the head-end system.

Create Processing Role For The Command

To create a processing role for your new command, add a value that designates your command to the PROC_ROLE_FLG lookup.

For example, suppose you were creating a custom command to support retrieving outage events for a device. Your lookup value might look like this:

Lookup Field Value

Description (Java Value Name)

CMRO

Retrieve Outage Events (retreiveOutageEvents)

Refer to the Oracle Utilities Application Framework documentation for more information about creating values for lookup fields.

Add Processing Role to Processing Method Business Object

Once the processing role lookup has been created, you have to add it as an Applicable Processing Role on the processing method business object that will be used to determine how to send out outbound communications. For most Oracle Utilities Smart Grid Gateway commands, this is the D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message) business object.

To continue the example of the "Retreive Outage Events" command, you would add the following option to the D1-HowToCreateActivityOBComm business object on the Main tab of the Business Object portal:

Option Type

Option Value

Applicable Processing Role

CMRO

Add Processing Role to Command Business Object

You must also add your processing role lookup as an Initiate Command Processing Role on the command (activity) business object you just created.

To continue the example of the "Retreive Outage Events" command, you would add the following option to the your activity business object on the Main tab of the Business Object portal:

Option Type

Option Value

Initiate Command Processing Role

CMRO

Add Processing Role/Method to Service Provider

You must also add your new processing role and corresponding processing method to the service provider that represents the head-end system.

To continue the example of the "Retreive Outage Events" command, you would add the following processing method to your head-end system service provider.

Processing Role

Processing Method

Retrieve Outage Events (CMRO)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of a retreive outage events command.

Create Outbound and Inbound Communications

The next step in enabling your new command is to create any necessary outbound and inbound communications to allow the messages related to the command to be sent/received to and from the head-end system. See Adapters for Issuing and Initiating Commands for more information about creating outbound and inbound communications.

Configure Middleware to Support New Messages

Lastly, you need to configure your middleware to support transformation of the communications used by your new command. For example, if your middleware uses XSLT to perform transformation, you need to add specifics about how to transform messages related to "Retreive Outage Events" command.

Creating Custom Commands

Oracle Utilities Smart Grid Gateway supports a number of commands, including:

•

Commission Device

•

Decommission Device

•

Device Status Check

•

On-Demand Read

•

Remote Connect

•

Remote Disconnect

However, most head-end systems provide additional commands beyond these. This section outlines the steps involved in creating custom commands, including:

•

Create Command (Activity) Business Objects

•

Create Processing Roles and Configure Processing Methods

•

Create Outbound and Inbound Communications

•

Configure Middleware to Support New Messages

Create Command (Activity) Business Objects

Each command available through Oracle Utilities Smart Grid Gateway is defined as an activity business object. For each custom command you wish to create, you must create an activity business object. The specifics of each business object are based on the type of command to be issuesd to the head-end system. The table below provides an example of the "Remote Connect" activity business object used by the Oracle Utilities Smart Grid Gateway.

Option

Description

Business Object

D1-RemoteConnect

Description

Remote Connect

Maintenance Object

D1-ACTIVITY (Activity)

Application Service

D1-REMOTECONNECTBOAS (Remote Connect BO)

Instance Control

Allow New Instances

Options

•

Applicable Processing Role: D1RC (Remote Connect)

•

Applicable Processing Role: D1SC (On-Demand Read - Scalar)

•

Applicable Processing Role: D1LC (Load Check)

•

Related Administration BO: D1-RemoteConnectType (Remote Connect Type)

•

Display UI Map: D1-RemoteConnectDisplay (Remote Connect - Display)

•

Portal Navigation Option: d1ActivityNavOpt (Activity Navigation Option)

•

Display Map Service Script: D1-RtRCDtls (Remote Connect - Retreive Details for Display)

•

Maintenance UI Map: D1-RemoteConnectMaint (Remote Connect - Maintenance)

Algorithms

•

Information: D1-CRAINFO (Command Request Activity Information)

•

Pre-Processing: D1-DETACTTYP (Determine Activity Type)

•

Pre-Processing: D1-DMRO (Default Measurement Requested Override)

•

Pre-Processing: D1-DDR (Determine Device and Recipient)

•

Validation: D1GINPVAL (Common Input Validation

•

Validation: D1-VALMDEST (Validate Measurement Destination)

•

Validation: D1-VALMREQO (Validate Measurement Requested Override)

Lifecycle

Note: Does not include "Transition to Default Next Status" monitor algorithms.

•

Pending

•

Validation

•

Enter: D1-VALACTTDI (Validate Actvity Type and Transition to Error State If Invalid)

•

Enter: D1-VALDVCNCD (Validate Device is not already Connected)

•

Enter: D1-VHCPODR (Validate Head-end’s Capability to perform On-Demand Read)

•

Enter: D1-VHCPCD (Validate Head-end’s Capability to perform Connect Disconnect)

•

Enter: D1-CECD (Check for existing future disconnects)

•

Validation Error

•

Monitor: D1-WTTMOUT (Wait Time Out)

•

Monitor: D1-RBOE (Rety BO in Error)

•

Enter: D1-CTDEBOE (Create To Do Entry for BO in Error)

•

Exit: D1-GTDCBO (Generic To Do Completion for BOs)

•

Waiting for Effective Date

•

Monitor: D1-WAITEFFDT (Wait for Effective Date)

•

Enter: D1-RRER (Send Received Response to External Requester)

•

Connection Ready

•

Enter: D1-CLCOC (Create Load Check Outbound Communication)

•

Enter: D1-CODROC (Create On-Demand Read for Start Measurement)

•

Enter: D1-CRCOC (Create Remote Connect Outbound Communication)

Lifecycle (continued)

Note: Does not include "Transition to Default Next Status" monitor algorithms.

•

Communication in Progress

•

Communication Error

•

Same as Validation Error (above)

•

Retry

•

Enter: D1-COOC (Cancel Outstanding Outbound Communication)

•

Execute Completion Events

•

Enter: D1-EXCMPEVTS (Execute Completion Events)

•

Completion Events Error

•

Same as Validation Error (above)

•

Waiting for Measurement

•

Monitor: D1-RMVCE (Retrieve Measurements via Completion Events)

•

Monitor: D1-RFINSC (Retrieve Scalar Final Measurements)

•

Monitor: D1-RSINIMS (Retrieve Scalar Initial Measurements)

•

Monitor: D1-WFMTO (Wait for Measurement Time Out)

•

Wait Expired

•

Same as Validation Error (above)

•

Completed

•

Enter: D1-SRCNTEA (Send Remote Connect Notification to Edge Application)

•

Enter: D1-SODRTEA (Send Start Measurement to Edge Application)

•

Discarded

•

Enter: D1-COOC (Cancel Outstanding Outbound Communication)

•

Enter: D1-COCE (Cancel Outstanding Completion Events)

•

Enter: D1-FAILPA (Fail Parent Activity)

•

Enter: D1-FRER (Sesnd Fail Response to External Requester)

Create Processing Roles and Configure Processing Methods

After the command activity business object has been created, you must also create a processing role for the command, and associate to your activity business object and the appropriate processing method business object, and then add the processing role/method for the command to the service provider that represents the head-end system.

Create Processing Role For The Command

To create a processing role for your new command, add a value that designates your command to the PROC_ROLE_FLG lookup.

For example, suppose you were creating a custom command to support retrieving outage events for a device. Your lookup value might look like this:

Lookup Field Value

Description (Java Value Name)

CMRO

Retrieve Outage Events (retreiveOutageEvents)

Refer to the Oracle Utilities Application Framework documentation for more information about creating values for lookup fields.

Add Processing Role to Processing Method Business Object

Once the processing role lookup has been created, you have to add it as an Applicable Processing Role on the processing method business object that will be used to determine how to send out outbound communications. For most Oracle Utilities Smart Grid Gateway commands, this is the D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message) business object.

To continue the example of the "Retreive Outage Events" command, you would add the following option to the D1-HowToCreateActivityOBComm business object on the Main tab of the Business Object portal:

Option Type

Option Value

Applicable Processing Role

CMRO

Add Processing Role to Command Business Object

You must also add your processing role lookup as an Initiate Command Processing Role on the command (activity) business object you just created.

To continue the example of the "Retreive Outage Events" command, you would add the following option to the your activity business object on the Main tab of the Business Object portal:

Option Type

Option Value

Initiate Command Processing Role

CMRO

Add Processing Role/Method to Service Provider

You must also add your new processing role and corresponding processing method to the service provider that represents the head-end system.

To continue the example of the "Retreive Outage Events" command, you would add the following processing method to your head-end system service provider.

Processing Role

Processing Method

Retrieve Outage Events (CMRO)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of a retreive outage events command.

Create Outbound and Inbound Communications

The next step in enabling your new command is to create any necessary outbound and inbound communications to allow the messages related to the command to be sent/received to and from the head-end system. See Adapters for Issuing and Initiating Commands for more information about creating outbound and inbound communications.

Configure Middleware to Support New Messages

Lastly, you need to configure your middleware to support transformation of the communications used by your new command. For example, if your middleware uses XSLT to perform transformation, you need to add specifics about how to transform messages related to "Retreive Outage Events" command.

Creating Custom Commands

Oracle Utilities Smart Grid Gateway supports a number of commands, including:

•

Commission Device

•

Decommission Device

•

Device Status Check

•

On-Demand Read

•

Remote Connect

•

Remote Disconnect

However, most head-end systems provide additional commands beyond these. This section outlines the steps involved in creating custom commands, including:

•

Create Command (Activity) Business Objects

•

Create Processing Roles and Configure Processing Methods

•

Create Outbound and Inbound Communications

•

Configure Middleware to Support New Messages

Create Command (Activity) Business Objects

Each command available through Oracle Utilities Smart Grid Gateway is defined as an activity business object. For each custom command you wish to create, you must create an activity business object. The specifics of each business object are based on the type of command to be issuesd to the head-end system. The table below provides an example of the "Remote Connect" activity business object used by the Oracle Utilities Smart Grid Gateway.

Option

Description

Business Object

D1-RemoteConnect

Description

Remote Connect

Maintenance Object

D1-ACTIVITY (Activity)

Application Service

D1-REMOTECONNECTBOAS (Remote Connect BO)

Instance Control

Allow New Instances

Options

•

Applicable Processing Role: D1RC (Remote Connect)

•

Applicable Processing Role: D1SC (On-Demand Read - Scalar)

•

Applicable Processing Role: D1LC (Load Check)

•

Related Administration BO: D1-RemoteConnectType (Remote Connect Type)

•

Display UI Map: D1-RemoteConnectDisplay (Remote Connect - Display)

•

Portal Navigation Option: d1ActivityNavOpt (Activity Navigation Option)

•

Display Map Service Script: D1-RtRCDtls (Remote Connect - Retreive Details for Display)

•

Maintenance UI Map: D1-RemoteConnectMaint (Remote Connect - Maintenance)

Algorithms

•

Information: D1-CRAINFO (Command Request Activity Information)

•

Pre-Processing: D1-DETACTTYP (Determine Activity Type)

•

Pre-Processing: D1-DMRO (Default Measurement Requested Override)

•

Pre-Processing: D1-DDR (Determine Device and Recipient)

•

Validation: D1GINPVAL (Common Input Validation

•

Validation: D1-VALMDEST (Validate Measurement Destination)

•

Validation: D1-VALMREQO (Validate Measurement Requested Override)

Lifecycle

Note: Does not include "Transition to Default Next Status" monitor algorithms.

•

Pending

•

Validation

•

Enter: D1-VALACTTDI (Validate Actvity Type and Transition to Error State If Invalid)

•

Enter: D1-VALDVCNCD (Validate Device is not already Connected)

•

Enter: D1-VHCPODR (Validate Head-end’s Capability to perform On-Demand Read)

•

Enter: D1-VHCPCD (Validate Head-end’s Capability to perform Connect Disconnect)

•

Enter: D1-CECD (Check for existing future disconnects)

•

Validation Error

•

Monitor: D1-WTTMOUT (Wait Time Out)

•

Monitor: D1-RBOE (Rety BO in Error)

•

Enter: D1-CTDEBOE (Create To Do Entry for BO in Error)

•

Exit: D1-GTDCBO (Generic To Do Completion for BOs)

•

Waiting for Effective Date

•

Monitor: D1-WAITEFFDT (Wait for Effective Date)

•

Enter: D1-RRER (Send Received Response to External Requester)

•

Connection Ready

•

Enter: D1-CLCOC (Create Load Check Outbound Communication)

•

Enter: D1-CODROC (Create On-Demand Read for Start Measurement)

•

Enter: D1-CRCOC (Create Remote Connect Outbound Communication)

Lifecycle (continued)

Note: Does not include "Transition to Default Next Status" monitor algorithms.

•

Communication in Progress

•

Communication Error

•

Same as Validation Error (above)

•

Retry

•

Enter: D1-COOC (Cancel Outstanding Outbound Communication)

•

Execute Completion Events

•

Enter: D1-EXCMPEVTS (Execute Completion Events)

•

Completion Events Error

•

Same as Validation Error (above)

•

Waiting for Measurement

•

Monitor: D1-RMVCE (Retrieve Measurements via Completion Events)

•

Monitor: D1-RFINSC (Retrieve Scalar Final Measurements)

•

Monitor: D1-RSINIMS (Retrieve Scalar Initial Measurements)

•

Monitor: D1-WFMTO (Wait for Measurement Time Out)

•

Wait Expired

•

Same as Validation Error (above)

•

Completed

•

Enter: D1-SRCNTEA (Send Remote Connect Notification to Edge Application)

•

Enter: D1-SODRTEA (Send Start Measurement to Edge Application)

•

Discarded

•

Enter: D1-COOC (Cancel Outstanding Outbound Communication)

•

Enter: D1-COCE (Cancel Outstanding Completion Events)

•

Enter: D1-FAILPA (Fail Parent Activity)

•

Enter: D1-FRER (Sesnd Fail Response to External Requester)

Create Processing Roles and Configure Processing Methods

After the command activity business object has been created, you must also create a processing role for the command, and associate to your activity business object and the appropriate processing method business object, and then add the processing role/method for the command to the service provider that represents the head-end system.

Create Processing Role For The Command

To create a processing role for your new command, add a value that designates your command to the PROC_ROLE_FLG lookup.

For example, suppose you were creating a custom command to support retrieving outage events for a device. Your lookup value might look like this:

Lookup Field Value

Description (Java Value Name)

CMRO

Retrieve Outage Events (retreiveOutageEvents)

Refer to the Oracle Utilities Application Framework documentation for more information about creating values for lookup fields.

Add Processing Role to Processing Method Business Object

Once the processing role lookup has been created, you have to add it as an Applicable Processing Role on the processing method business object that will be used to determine how to send out outbound communications. For most Oracle Utilities Smart Grid Gateway commands, this is the D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message) business object.

To continue the example of the "Retreive Outage Events" command, you would add the following option to the D1-HowToCreateActivityOBComm business object on the Main tab of the Business Object portal:

Option Type

Option Value

Applicable Processing Role

CMRO

Add Processing Role to Command Business Object

You must also add your processing role lookup as an Initiate Command Processing Role on the command (activity) business object you just created.

To continue the example of the "Retreive Outage Events" command, you would add the following option to the your activity business object on the Main tab of the Business Object portal:

Option Type

Option Value

Initiate Command Processing Role

CMRO

Add Processing Role/Method to Service Provider

You must also add your new processing role and corresponding processing method to the service provider that represents the head-end system.

To continue the example of the "Retreive Outage Events" command, you would add the following processing method to your head-end system service provider.

Processing Role

Processing Method

Retrieve Outage Events (CMRO)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of a retreive outage events command.

Create Outbound and Inbound Communications

The next step in enabling your new command is to create any necessary outbound and inbound communications to allow the messages related to the command to be sent/received to and from the head-end system. See Adapters for Issuing and Initiating Commands for more information about creating outbound and inbound communications.

Configure Middleware to Support New Messages

Lastly, you need to configure your middleware to support transformation of the communications used by your new command. For example, if your middleware uses XSLT to perform transformation, you need to add specifics about how to transform messages related to "Retreive Outage Events" command.

Creating Custom Commands

Oracle Utilities Smart Grid Gateway supports a number of commands, including:

•

Commission Device

•

Decommission Device

•

Device Status Check

•

On-Demand Read

•

Remote Connect

•

Remote Disconnect

However, most head-end systems provide additional commands beyond these. This section outlines the steps involved in creating custom commands, including:

•

Create Command (Activity) Business Objects

•

Create Processing Roles and Configure Processing Methods

•

Create Outbound and Inbound Communications

•

Configure Middleware to Support New Messages

Create Command (Activity) Business Objects

Each command available through Oracle Utilities Smart Grid Gateway is defined as an activity business object. For each custom command you wish to create, you must create an activity business object. The specifics of each business object are based on the type of command to be issuesd to the head-end system. The table below provides an example of the "Remote Connect" activity business object used by the Oracle Utilities Smart Grid Gateway.

Option

Description

Business Object

D1-RemoteConnect

Description

Remote Connect

Maintenance Object

D1-ACTIVITY (Activity)

Application Service

D1-REMOTECONNECTBOAS (Remote Connect BO)

Instance Control

Allow New Instances

Options

•

Applicable Processing Role: D1RC (Remote Connect)

•

Applicable Processing Role: D1SC (On-Demand Read - Scalar)

•

Applicable Processing Role: D1LC (Load Check)

•

Related Administration BO: D1-RemoteConnectType (Remote Connect Type)

•

Display UI Map: D1-RemoteConnectDisplay (Remote Connect - Display)

•

Portal Navigation Option: d1ActivityNavOpt (Activity Navigation Option)

•

Display Map Service Script: D1-RtRCDtls (Remote Connect - Retreive Details for Display)

•

Maintenance UI Map: D1-RemoteConnectMaint (Remote Connect - Maintenance)

Algorithms

•

Information: D1-CRAINFO (Command Request Activity Information)

•

Pre-Processing: D1-DETACTTYP (Determine Activity Type)

•

Pre-Processing: D1-DMRO (Default Measurement Requested Override)

•

Pre-Processing: D1-DDR (Determine Device and Recipient)

•

Validation: D1GINPVAL (Common Input Validation

•

Validation: D1-VALMDEST (Validate Measurement Destination)

•

Validation: D1-VALMREQO (Validate Measurement Requested Override)

Lifecycle

Note: Does not include "Transition to Default Next Status" monitor algorithms.

•

Pending

•

Validation

•

Enter: D1-VALACTTDI (Validate Actvity Type and Transition to Error State If Invalid)

•

Enter: D1-VALDVCNCD (Validate Device is not already Connected)

•

Enter: D1-VHCPODR (Validate Head-end’s Capability to perform On-Demand Read)

•

Enter: D1-VHCPCD (Validate Head-end’s Capability to perform Connect Disconnect)

•

Enter: D1-CECD (Check for existing future disconnects)

•

Validation Error

•

Monitor: D1-WTTMOUT (Wait Time Out)

•

Monitor: D1-RBOE (Rety BO in Error)

•

Enter: D1-CTDEBOE (Create To Do Entry for BO in Error)

•

Exit: D1-GTDCBO (Generic To Do Completion for BOs)

•

Waiting for Effective Date

•

Monitor: D1-WAITEFFDT (Wait for Effective Date)

•

Enter: D1-RRER (Send Received Response to External Requester)

•

Connection Ready

•

Enter: D1-CLCOC (Create Load Check Outbound Communication)

•

Enter: D1-CODROC (Create On-Demand Read for Start Measurement)

•

Enter: D1-CRCOC (Create Remote Connect Outbound Communication)

Lifecycle (continued)

Note: Does not include "Transition to Default Next Status" monitor algorithms.

•

Communication in Progress

•

Communication Error

•

Same as Validation Error (above)

•

Retry

•

Enter: D1-COOC (Cancel Outstanding Outbound Communication)

•

Execute Completion Events

•

Enter: D1-EXCMPEVTS (Execute Completion Events)

•

Completion Events Error

•

Same as Validation Error (above)

•

Waiting for Measurement

•

Monitor: D1-RMVCE (Retrieve Measurements via Completion Events)

•

Monitor: D1-RFINSC (Retrieve Scalar Final Measurements)

•

Monitor: D1-RSINIMS (Retrieve Scalar Initial Measurements)

•

Monitor: D1-WFMTO (Wait for Measurement Time Out)

•

Wait Expired

•

Same as Validation Error (above)

•

Completed

•

Enter: D1-SRCNTEA (Send Remote Connect Notification to Edge Application)

•

Enter: D1-SODRTEA (Send Start Measurement to Edge Application)

•

Discarded

•

Enter: D1-COOC (Cancel Outstanding Outbound Communication)

•

Enter: D1-COCE (Cancel Outstanding Completion Events)

•

Enter: D1-FAILPA (Fail Parent Activity)

•

Enter: D1-FRER (Sesnd Fail Response to External Requester)

Create Processing Roles and Configure Processing Methods

After the command activity business object has been created, you must also create a processing role for the command, and associate to your activity business object and the appropriate processing method business object, and then add the processing role/method for the command to the service provider that represents the head-end system.

Create Processing Role For The Command

To create a processing role for your new command, add a value that designates your command to the PROC_ROLE_FLG lookup.

For example, suppose you were creating a custom command to support retrieving outage events for a device. Your lookup value might look like this:

Lookup Field Value

Description (Java Value Name)

CMRO

Retrieve Outage Events (retreiveOutageEvents)

Refer to the Oracle Utilities Application Framework documentation for more information about creating values for lookup fields.

Add Processing Role to Processing Method Business Object

Once the processing role lookup has been created, you have to add it as an Applicable Processing Role on the processing method business object that will be used to determine how to send out outbound communications. For most Oracle Utilities Smart Grid Gateway commands, this is the D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message) business object.

To continue the example of the "Retreive Outage Events" command, you would add the following option to the D1-HowToCreateActivityOBComm business object on the Main tab of the Business Object portal:

Option Type

Option Value

Applicable Processing Role

CMRO

Add Processing Role to Command Business Object

You must also add your processing role lookup as an Initiate Command Processing Role on the command (activity) business object you just created.

To continue the example of the "Retreive Outage Events" command, you would add the following option to the your activity business object on the Main tab of the Business Object portal:

Option Type

Option Value

Initiate Command Processing Role

CMRO

Add Processing Role/Method to Service Provider

You must also add your new processing role and corresponding processing method to the service provider that represents the head-end system.

To continue the example of the "Retreive Outage Events" command, you would add the following processing method to your head-end system service provider.

Processing Role

Processing Method

Retrieve Outage Events (CMRO)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of a retreive outage events command.

Create Outbound and Inbound Communications

The next step in enabling your new command is to create any necessary outbound and inbound communications to allow the messages related to the command to be sent/received to and from the head-end system. See Adapters for Issuing and Initiating Commands for more information about creating outbound and inbound communications.

Configure Middleware to Support New Messages

Lastly, you need to configure your middleware to support transformation of the communications used by your new command. For example, if your middleware uses XSLT to perform transformation, you need to add specifics about how to transform messages related to "Retreive Outage Events" command.

Creating Custom Commands

Oracle Utilities Smart Grid Gateway supports a number of commands, including:

•

Commission Device

•

Decommission Device

•

Device Status Check

•

On-Demand Read

•

Remote Connect

•

Remote Disconnect

However, most head-end systems provide additional commands beyond these. This section outlines the steps involved in creating custom commands, including:

•

Create Command (Activity) Business Objects

•

Create Processing Roles and Configure Processing Methods

•

Create Outbound and Inbound Communications

•

Configure Middleware to Support New Messages

Create Command (Activity) Business Objects

Each command available through Oracle Utilities Smart Grid Gateway is defined as an activity business object. For each custom command you wish to create, you must create an activity business object. The specifics of each business object are based on the type of command to be issuesd to the head-end system. The table below provides an example of the "Remote Connect" activity business object used by the Oracle Utilities Smart Grid Gateway.

Option

Description

Business Object

D1-RemoteConnect

Description

Remote Connect

Maintenance Object

D1-ACTIVITY (Activity)

Application Service

D1-REMOTECONNECTBOAS (Remote Connect BO)

Instance Control

Allow New Instances

Options

•

Applicable Processing Role: D1RC (Remote Connect)

•

Applicable Processing Role: D1SC (On-Demand Read - Scalar)

•

Applicable Processing Role: D1LC (Load Check)

•

Related Administration BO: D1-RemoteConnectType (Remote Connect Type)

•

Display UI Map: D1-RemoteConnectDisplay (Remote Connect - Display)

•

Portal Navigation Option: d1ActivityNavOpt (Activity Navigation Option)

•

Display Map Service Script: D1-RtRCDtls (Remote Connect - Retreive Details for Display)

•

Maintenance UI Map: D1-RemoteConnectMaint (Remote Connect - Maintenance)

Algorithms

•

Information: D1-CRAINFO (Command Request Activity Information)

•

Pre-Processing: D1-DETACTTYP (Determine Activity Type)

•

Pre-Processing: D1-DMRO (Default Measurement Requested Override)

•

Pre-Processing: D1-DDR (Determine Device and Recipient)

•

Validation: D1GINPVAL (Common Input Validation

•

Validation: D1-VALMDEST (Validate Measurement Destination)

•

Validation: D1-VALMREQO (Validate Measurement Requested Override)

Lifecycle

Note: Does not include "Transition to Default Next Status" monitor algorithms.

•

Pending

•

Validation

•

Enter: D1-VALACTTDI (Validate Actvity Type and Transition to Error State If Invalid)

•

Enter: D1-VALDVCNCD (Validate Device is not already Connected)

•

Enter: D1-VHCPODR (Validate Head-end’s Capability to perform On-Demand Read)

•

Enter: D1-VHCPCD (Validate Head-end’s Capability to perform Connect Disconnect)

•

Enter: D1-CECD (Check for existing future disconnects)

•

Validation Error

•

Monitor: D1-WTTMOUT (Wait Time Out)

•

Monitor: D1-RBOE (Rety BO in Error)

•

Enter: D1-CTDEBOE (Create To Do Entry for BO in Error)

•

Exit: D1-GTDCBO (Generic To Do Completion for BOs)

•

Waiting for Effective Date

•

Monitor: D1-WAITEFFDT (Wait for Effective Date)

•

Enter: D1-RRER (Send Received Response to External Requester)

•

Connection Ready

•

Enter: D1-CLCOC (Create Load Check Outbound Communication)

•

Enter: D1-CODROC (Create On-Demand Read for Start Measurement)

•

Enter: D1-CRCOC (Create Remote Connect Outbound Communication)

Lifecycle (continued)

Note: Does not include "Transition to Default Next Status" monitor algorithms.

•

Communication in Progress

•

Communication Error

•

Same as Validation Error (above)

•

Retry

•

Enter: D1-COOC (Cancel Outstanding Outbound Communication)

•

Execute Completion Events

•

Enter: D1-EXCMPEVTS (Execute Completion Events)

•

Completion Events Error

•

Same as Validation Error (above)

•

Waiting for Measurement

•

Monitor: D1-RMVCE (Retrieve Measurements via Completion Events)

•

Monitor: D1-RFINSC (Retrieve Scalar Final Measurements)

•

Monitor: D1-RSINIMS (Retrieve Scalar Initial Measurements)

•

Monitor: D1-WFMTO (Wait for Measurement Time Out)

•

Wait Expired

•

Same as Validation Error (above)

•

Completed

•

Enter: D1-SRCNTEA (Send Remote Connect Notification to Edge Application)

•

Enter: D1-SODRTEA (Send Start Measurement to Edge Application)

•

Discarded

•

Enter: D1-COOC (Cancel Outstanding Outbound Communication)

•

Enter: D1-COCE (Cancel Outstanding Completion Events)

•

Enter: D1-FAILPA (Fail Parent Activity)

•

Enter: D1-FRER (Sesnd Fail Response to External Requester)

Create Processing Roles and Configure Processing Methods

After the command activity business object has been created, you must also create a processing role for the command, and associate to your activity business object and the appropriate processing method business object, and then add the processing role/method for the command to the service provider that represents the head-end system.

Create Processing Role For The Command

To create a processing role for your new command, add a value that designates your command to the PROC_ROLE_FLG lookup.

For example, suppose you were creating a custom command to support retrieving outage events for a device. Your lookup value might look like this:

Lookup Field Value

Description (Java Value Name)

CMRO

Retrieve Outage Events (retreiveOutageEvents)

Refer to the Oracle Utilities Application Framework documentation for more information about creating values for lookup fields.

Add Processing Role to Processing Method Business Object

Once the processing role lookup has been created, you have to add it as an Applicable Processing Role on the processing method business object that will be used to determine how to send out outbound communications. For most Oracle Utilities Smart Grid Gateway commands, this is the D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message) business object.

To continue the example of the "Retreive Outage Events" command, you would add the following option to the D1-HowToCreateActivityOBComm business object on the Main tab of the Business Object portal:

Option Type

Option Value

Applicable Processing Role

CMRO

Add Processing Role to Command Business Object

You must also add your processing role lookup as an Initiate Command Processing Role on the command (activity) business object you just created.

To continue the example of the "Retreive Outage Events" command, you would add the following option to the your activity business object on the Main tab of the Business Object portal:

Option Type

Option Value

Initiate Command Processing Role

CMRO

Add Processing Role/Method to Service Provider

You must also add your new processing role and corresponding processing method to the service provider that represents the head-end system.

To continue the example of the "Retreive Outage Events" command, you would add the following processing method to your head-end system service provider.

Processing Role

Processing Method

Retrieve Outage Events (CMRO)

D1-HowToCreateActivityOBComm (How To Create OB Communication/Send OB Message)

This processing method specifies the type of outbound communication business object and outbound message type to use when sending outbound communications to a head-end system as a result of a retreive outage events command.

Create Outbound and Inbound Communications

The next step in enabling your new command is to create any necessary outbound and inbound communications to allow the messages related to the command to be sent/received to and from the head-end system. See Adapters for Issuing and Initiating Commands for more information about creating outbound and inbound communications.

Configure Middleware to Support New Messages

Lastly, you need to configure your middleware to support transformation of the communications used by your new command. For example, if your middleware uses XSLT to perform transformation, you need to add specifics about how to transform messages related to "Retreive Outage Events" command.

Initial Measurement and Device Event XML Formats

This section provides details concerning the XML formats used when importing initial measurements and device events, including:

•

Initial Measurement Data XML Format

•

Device Event XML Format

Initial Measurement Data XML Format

This section describes the XML format used for inbound initial measurement data. This includes interval and scalar examples, descriptions of the individual XML elements, and the initial measurement data XML schema based on the D1-IMDSeeder business object.

Example - Interval Initial Measurement Data

<IMD-IMPORT>

<serviceProvider>HEADEND-1</serviceProvider>

<serviceProviderExternalId>MDCS-1</serviceProviderExternalId>

<preVEE>

</simdId>

<dvcIdN>037090184721</dvcIdN>

<mcId>135914144111</mcId>

<mcIdN>123</mcIdN>

<externalId>IMD1234567</externalId>

<uom>KWH</uom>

<stDt>2009-01-02-00.00.00</stDt>

</stQty>

<enDt>2009-01-03-00.00.00</enDt>

</enQty>

<imdType>D1IL</imdType>

<mcIS>D1IN</mcIS>

<inShift>N</inShift>

<mcm>1.0</mcm>

</nd>

<tz>USPACIFIC</tz>

<spi>3600</spi>

</ccond>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

<msrs>

<mL>

<s>1</s>

<q>1.6</q>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</mL>

<mL>

<s>2</s>

<q>1.57</q>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</mL>

<mL>

<s>3</s>

<q>0.0</q>

<sts>

<stsL>

<s>1</s>

<st>MISSING</st>

<s>2</s>

<st>OUTAGE</st>

</stsL>

</sts>

</mL>

<mL>

<s>4</s>

<q>0.0</q>

<sts>

<stsL>

<s>1</s>

<st>MISSING</st>

<s>2</s>

<st>OUTAGE</st>

</stsL>

</sts>

</mL>

<mL>

<s>5</s>

<q>1.0</q>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</mL>

<mL>

<s>6</s>

<q>1.45</q>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</mL>

...

</msrs>

</preVEE>

</IMD-IMPORT>

Example - Scalar Initial Measurement Data

<IMD-IMPORT>

<serviceProvider>HEADEND-2</serviceProvider>

<serviceProviderExternalId>MDCS-2</serviceProviderExternalId>

<preVEE>

<dvcIdN>037090184721</dvcIdN>

<mcId>327604570580</mcId>

<mcIdN>123</mcIdN>

<externalId>IMD7654321</externalId>

<uom>KWH</uom>

<stDt>2009-01-31-11.25.00</stDt>

</stQty>

<enDt>2009-02-28-13.13.00</enDt>

<enQty>110.00</enQty>

<imdType>D1IL</imdType>

<mcIS>D1SC</mcIS>

<inShift>N</inShift>

<mcm>1.0</mcm>

<nd>5</nd>

<tz>USPACIFIC</tz>

</ccond>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</preVEE>

<processData>

</isShiftStartEnd>

</isShiftedIntervals>

</isErrorEncountered>

</servicePointId>

</installationConstant>

</deviceId>

</logs>

<deviceEventTypes>

<deviceEventTypesList>

<deviceEventType>BROKEN</deviceEventType>

</deviceEventTypesList>

</deviceEventTypes>

</processData>

</IMD-IMPORT>

Element Descriptions - Initial Measurement Data

The table below provides descriptions of the elements used in the initial measurement data XML format.

Element

Description

<{SERVICE_NAME}>

Root element containing an initial measurement. This element should match the name of the inbound service used to import the usage.

<serviceProvider>

Name of the head-end system (defined as a service provider) in MDM

<serviceProviderExternalId>

External ID of the head-end system.

<preVEE>

Element containing Pre VEE measurement data

<simdId>

The ID of a specific initial measurement

<dvcIdN>

Device Identifier Number, e.g. a Serial Number. The "type" of device identifier that the head-end system understands is configured within MDM - and so can differ per head-end.

<mcId>

Measuring Component ID

<mcIdN>

Measuring Component Identifier Number. Populated with channel ID. The "type" of measuring component identifier that the head-end system understands is configured within MDM

<externalId>

File name of ID of the XML document containing the measurement data

<uom>

Unit of Measure (Optional)

<stDt>

Start Date/Time. Required for interval measurement data. Optional for scalar measurement data. Must be in the following format:

YYYY-MM-DD-HH.MM.SS

Example:2008-12-31-00.30.00

<stQty>

Start Reading. Optional.

<enDt>

End Date/Time. Required.

Must be in the following format:

YYYY-MM-DD-HH.MM.SS

Example:2008-12-31-00.30.00

<enQty>

End Reading. Required for scalar measurements.

<imdType>

Initial measurement data type. Valid values include:

•

D1IL (Initial Load)

•

D1MO (Manual)

•

D1ES (Estimation)

Defaults to D1IL (Initial Load) if not supplied.

<mcIS>

Interval Scalar flag. Indicates if the data is for an interval or scalar measuring component.

<inShift>

Incoming Data Shift flag. Indicates if the device is DST aware.

<mcm>

Meter multiplier.

<nd>

Number of Dials

<tz>

Time Zone

<spi>

Seconds-per-interval

<ccond>

Measurement condition

<sts>

Element containing status code information for entire measurement.

<stsL>

List of head-end system status codes for the entire measurement

<s>

Sequence

<st>

Head-end status codes applicable to the entire set of data.

<msrs>

Element containing measurement data

<mL>

Element containing an individual interval measurements. Used for interval measurement data only.

<s>

Sequence of the interval measurement

<dt>

Date and time of the interval measurement. Optional.

<q>

Quantity of the interval measurement

<ue>

Used-Edited flag. Indicates if the interval measurement has been manually edited

<fc>

Final Condition code for the interval measurement. Optional.

<sts>

Element containing lists of status codes for each interval measurement

<stsL>

Element containing a sequence/status pairing for each interval measurement

<s>

Sequence of the status code for this interval measurement.

<st>

Head-end status code of the interval measurement.

<processData>

Element containing processing-related data.

</deviceEventTypes>

Element containing one or more lists of device event types (used to capture Reader Remarks for scalar measurements)

<deviceEventTypesList>

Element containing one or more device event types (used to capture Reader Remarks for scalar measurements)

<deviceEventType>

A device event type code that represents a Reader Remark (used with scalar measurements)

Schema - IMD Seeder (D1-IMDSeeder) Business Object

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ouaf="http://ouaf.oracle.com/" targetNamespace="http://oracle.com/D1-InitialLoadIMD.xsd" elementFormDefault="qualified">

<xsd:import namespace="http://ouaf.oracle.com/" />

<xsd:element name="D1-InitialLoadIMD">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="initialMeasurementDataId" type="xsd:string" minOccurs="0" />

<xsd:element name="preVEE" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="simdId" type="xsd:string" minOccurs="0" />

<xsd:element name="dvcIdN" type="xsd:string" minOccurs="0" />

<xsd:element name="mcId" type="xsd:string" minOccurs="0" />

<xsd:element name="mcIdN" type="xsd:string" minOccurs="0" />

<xsd:element name="externalId" type="xsd:string" minOccurs="0" />

<xsd:element name="uom" type="xsd:string" minOccurs="0" />

<xsd:element name="externalUOM" type="xsd:string" minOccurs="0" />

<xsd:element name="stDt" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="stQty" type="xsd:decimal" minOccurs="0" />

<xsd:element name="enDt" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="enQty" type="xsd:decimal" minOccurs="0" />

<xsd:element name="imdType" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="estimation" />

<xsd:enumeration value="imdSeeder" />

<xsd:enumeration value="initialLoad" />

<xsd:enumeration value="manual" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="inShift" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="notShifted" />

<xsd:enumeration value="shifted" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="mcm" type="xsd:decimal" minOccurs="0" />

<xsd:element name="nd" type="xsd:decimal" minOccurs="0" />

<xsd:element name="tz" type="xsd:string" minOccurs="0" />

<xsd:element name="spi" type="xsd:int" minOccurs="0" />

<xsd:element name="ccond" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="301000" />

<xsd:enumeration value="901000" />

<xsd:enumeration value="501000" />

<xsd:enumeration value="101000" />

<xsd:enumeration value="100000" />

<xsd:enumeration value="201000" />

<xsd:enumeration value="401000" />

<xsd:enumeration value="402000" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="sts" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="stsL" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="s" type="xsd:decimal" minOccurs="0" />

<xsd:element name="st" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="msrs" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="mL" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="s" type="xsd:decimal" minOccurs="0" />

<xsd:element name="dt" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="q" type="xsd:decimal" minOccurs="0" />

<xsd:element name="ue" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="userEdited" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="fc" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="301000" />

<xsd:enumeration value="901000" />

<xsd:enumeration value="501000" />

<xsd:enumeration value="101000" />

<xsd:enumeration value="100000" />

<xsd:enumeration value="201000" />

<xsd:enumeration value="401000" />

<xsd:enumeration value="402000" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="sts" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="stsL" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="s" type="xsd:decimal" minOccurs="0" />

<xsd:element name="st" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="rawData" type="xsd:anyType" minOccurs="0" maxOccurs="unbounded" />

<xsd:element name="processData" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="isShiftedStartEnd" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="isShiftedIntervals" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="isErrorEncountered" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="servicePointId" type="xsd:string" minOccurs="0" />

<xsd:element name="installationConstant" type="xsd:decimal" minOccurs="0" />

<xsd:element name="deviceId" type="xsd:string" minOccurs="0" />

<xsd:element name="logs" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="logsList" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="logsEntry" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="sequence" type="xsd:decimal" minOccurs="0" />

<xsd:element name="mo" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue1" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue2" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue3" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue4" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue5" type="xsd:string" minOccurs="0" />

<xsd:element name="logEntryType" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="toDos" />

<xsd:enumeration value="created" />

<xsd:enumeration value="statusTransitionError" />

<xsd:enumeration value="exception" />

<xsd:enumeration value="statusTransition" />

<xsd:enumeration value="system" />

<xsd:enumeration value="toDo" />

<xsd:enumeration value="userDetails" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="logDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="boStatus" type="xsd:string" minOccurs="0" />

<xsd:element name="description" type="xsd:string" minOccurs="0" />

<xsd:element name="user" type="xsd:string" minOccurs="0" />

<xsd:element name="logMessage" type="xsd:string" minOccurs="0" />

<xsd:element name="characteristicType" type="xsd:string" minOccurs="0" />

<xsd:element name="characteristicValue" type="xsd:string" minOccurs="0" />

<xsd:element name="adhocValue" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue1" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue2" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue3" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue4" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue5" type="xsd:string" minOccurs="0" />

<xsd:element name="messageCategory" type="xsd:decimal" minOccurs="0" />

<xsd:element name="messageNumber" type="xsd:decimal" minOccurs="0" />

<xsd:element name="messageParm1" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm2" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm3" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm4" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm5" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm6" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm7" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm8" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm9" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="deviceEventTypes" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="deviceEventTypesList" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="deviceEventType" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="boStatus" type="xsd:string" minOccurs="0" />

<xsd:element name="statusReason" type="xsd:string" minOccurs="0" />

<xsd:element name="bo" type="xsd:string" />

<xsd:element name="creationDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="boStatusDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="isTraceOn" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="isIntervalDateTimePopulated">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="isReprocessPerformed" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="serviceProvider" type="xsd:string" minOccurs="0" />

<xsd:element name="serviceProviderExternalId" type="xsd:string" minOccurs="0" />

<xsd:element name="fromDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="toDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="timeZone" type="xsd:string" minOccurs="0" />

<xsd:element name="isAutomatedRetry" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="retryUntilDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="version" type="xsd:decimal" minOccurs="0" />

</xsd:sequence>

<xsd:attribute name="dateTimeTagFormat" type="xsd:string" fixed="xsd" use="required" />

<xsd:attribute name="transactionType">

<xsd:simpleType>

<xsd:restriction base="xsd:token">

<xsd:enumeration value="RWOV" />

<xsd:enumeration value="FADD" />

<xsd:enumeration value="FUPD" />

<xsd:enumeration value="DEL" />

<xsd:enumeration value="UPD" />

<xsd:enumeration value="ADD" />

<xsd:enumeration value="READ" />

<xsd:enumeration value="REPL" />

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Initial Measurement Data XML Format

This section describes the XML format used for inbound initial measurement data. This includes interval and scalar examples, descriptions of the individual XML elements, and the initial measurement data XML schema based on the D1-IMDSeeder business object.

Example - Interval Initial Measurement Data

<IMD-IMPORT>

<serviceProvider>HEADEND-1</serviceProvider>

<serviceProviderExternalId>MDCS-1</serviceProviderExternalId>

<preVEE>

</simdId>

<dvcIdN>037090184721</dvcIdN>

<mcId>135914144111</mcId>

<mcIdN>123</mcIdN>

<externalId>IMD1234567</externalId>

<uom>KWH</uom>

<stDt>2009-01-02-00.00.00</stDt>

</stQty>

<enDt>2009-01-03-00.00.00</enDt>

</enQty>

<imdType>D1IL</imdType>

<mcIS>D1IN</mcIS>

<inShift>N</inShift>

<mcm>1.0</mcm>

</nd>

<tz>USPACIFIC</tz>

<spi>3600</spi>

</ccond>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

<msrs>

<mL>

<s>1</s>

<q>1.6</q>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</mL>

<mL>

<s>2</s>

<q>1.57</q>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</mL>

<mL>

<s>3</s>

<q>0.0</q>

<sts>

<stsL>

<s>1</s>

<st>MISSING</st>

<s>2</s>

<st>OUTAGE</st>

</stsL>

</sts>

</mL>

<mL>

<s>4</s>

<q>0.0</q>

<sts>

<stsL>

<s>1</s>

<st>MISSING</st>

<s>2</s>

<st>OUTAGE</st>

</stsL>

</sts>

</mL>

<mL>

<s>5</s>

<q>1.0</q>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</mL>

<mL>

<s>6</s>

<q>1.45</q>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</mL>

...

</msrs>

</preVEE>

</IMD-IMPORT>

Example - Scalar Initial Measurement Data

<IMD-IMPORT>

<serviceProvider>HEADEND-2</serviceProvider>

<serviceProviderExternalId>MDCS-2</serviceProviderExternalId>

<preVEE>

<dvcIdN>037090184721</dvcIdN>

<mcId>327604570580</mcId>

<mcIdN>123</mcIdN>

<externalId>IMD7654321</externalId>

<uom>KWH</uom>

<stDt>2009-01-31-11.25.00</stDt>

</stQty>

<enDt>2009-02-28-13.13.00</enDt>

<enQty>110.00</enQty>

<imdType>D1IL</imdType>

<mcIS>D1SC</mcIS>

<inShift>N</inShift>

<mcm>1.0</mcm>

<nd>5</nd>

<tz>USPACIFIC</tz>

</ccond>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</preVEE>

<processData>

</isShiftStartEnd>

</isShiftedIntervals>

</isErrorEncountered>

</servicePointId>

</installationConstant>

</deviceId>

</logs>

<deviceEventTypes>

<deviceEventTypesList>

<deviceEventType>BROKEN</deviceEventType>

</deviceEventTypesList>

</deviceEventTypes>

</processData>

</IMD-IMPORT>

Element Descriptions - Initial Measurement Data

The table below provides descriptions of the elements used in the initial measurement data XML format.

Element

Description

<{SERVICE_NAME}>

Root element containing an initial measurement. This element should match the name of the inbound service used to import the usage.

<serviceProvider>

Name of the head-end system (defined as a service provider) in MDM

<serviceProviderExternalId>

External ID of the head-end system.

<preVEE>

Element containing Pre VEE measurement data

<simdId>

The ID of a specific initial measurement

<dvcIdN>

Device Identifier Number, e.g. a Serial Number. The "type" of device identifier that the head-end system understands is configured within MDM - and so can differ per head-end.

<mcId>

Measuring Component ID

<mcIdN>

Measuring Component Identifier Number. Populated with channel ID. The "type" of measuring component identifier that the head-end system understands is configured within MDM

<externalId>

File name of ID of the XML document containing the measurement data

<uom>

Unit of Measure (Optional)

<stDt>

Start Date/Time. Required for interval measurement data. Optional for scalar measurement data. Must be in the following format:

YYYY-MM-DD-HH.MM.SS

Example:2008-12-31-00.30.00

<stQty>

Start Reading. Optional.

<enDt>

End Date/Time. Required.

Must be in the following format:

YYYY-MM-DD-HH.MM.SS

Example:2008-12-31-00.30.00

<enQty>

End Reading. Required for scalar measurements.

<imdType>

Initial measurement data type. Valid values include:

•

D1IL (Initial Load)

•

D1MO (Manual)

•

D1ES (Estimation)

Defaults to D1IL (Initial Load) if not supplied.

<mcIS>

Interval Scalar flag. Indicates if the data is for an interval or scalar measuring component.

<inShift>

Incoming Data Shift flag. Indicates if the device is DST aware.

<mcm>

Meter multiplier.

<nd>

Number of Dials

<tz>

Time Zone

<spi>

Seconds-per-interval

<ccond>

Measurement condition

<sts>

Element containing status code information for entire measurement.

<stsL>

List of head-end system status codes for the entire measurement

<s>

Sequence

<st>

Head-end status codes applicable to the entire set of data.

<msrs>

Element containing measurement data

<mL>

Element containing an individual interval measurements. Used for interval measurement data only.

<s>

Sequence of the interval measurement

<dt>

Date and time of the interval measurement. Optional.

<q>

Quantity of the interval measurement

<ue>

Used-Edited flag. Indicates if the interval measurement has been manually edited

<fc>

Final Condition code for the interval measurement. Optional.

<sts>

Element containing lists of status codes for each interval measurement

<stsL>

Element containing a sequence/status pairing for each interval measurement

<s>

Sequence of the status code for this interval measurement.

<st>

Head-end status code of the interval measurement.

<processData>

Element containing processing-related data.

</deviceEventTypes>

Element containing one or more lists of device event types (used to capture Reader Remarks for scalar measurements)

<deviceEventTypesList>

Element containing one or more device event types (used to capture Reader Remarks for scalar measurements)

<deviceEventType>

A device event type code that represents a Reader Remark (used with scalar measurements)

Schema - IMD Seeder (D1-IMDSeeder) Business Object

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ouaf="http://ouaf.oracle.com/" targetNamespace="http://oracle.com/D1-InitialLoadIMD.xsd" elementFormDefault="qualified">

<xsd:import namespace="http://ouaf.oracle.com/" />

<xsd:element name="D1-InitialLoadIMD">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="initialMeasurementDataId" type="xsd:string" minOccurs="0" />

<xsd:element name="preVEE" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="simdId" type="xsd:string" minOccurs="0" />

<xsd:element name="dvcIdN" type="xsd:string" minOccurs="0" />

<xsd:element name="mcId" type="xsd:string" minOccurs="0" />

<xsd:element name="mcIdN" type="xsd:string" minOccurs="0" />

<xsd:element name="externalId" type="xsd:string" minOccurs="0" />

<xsd:element name="uom" type="xsd:string" minOccurs="0" />

<xsd:element name="externalUOM" type="xsd:string" minOccurs="0" />

<xsd:element name="stDt" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="stQty" type="xsd:decimal" minOccurs="0" />

<xsd:element name="enDt" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="enQty" type="xsd:decimal" minOccurs="0" />

<xsd:element name="imdType" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="estimation" />

<xsd:enumeration value="imdSeeder" />

<xsd:enumeration value="initialLoad" />

<xsd:enumeration value="manual" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="inShift" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="notShifted" />

<xsd:enumeration value="shifted" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="mcm" type="xsd:decimal" minOccurs="0" />

<xsd:element name="nd" type="xsd:decimal" minOccurs="0" />

<xsd:element name="tz" type="xsd:string" minOccurs="0" />

<xsd:element name="spi" type="xsd:int" minOccurs="0" />

<xsd:element name="ccond" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="301000" />

<xsd:enumeration value="901000" />

<xsd:enumeration value="501000" />

<xsd:enumeration value="101000" />

<xsd:enumeration value="100000" />

<xsd:enumeration value="201000" />

<xsd:enumeration value="401000" />

<xsd:enumeration value="402000" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="sts" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="stsL" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="s" type="xsd:decimal" minOccurs="0" />

<xsd:element name="st" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="msrs" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="mL" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="s" type="xsd:decimal" minOccurs="0" />

<xsd:element name="dt" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="q" type="xsd:decimal" minOccurs="0" />

<xsd:element name="ue" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="userEdited" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="fc" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="301000" />

<xsd:enumeration value="901000" />

<xsd:enumeration value="501000" />

<xsd:enumeration value="101000" />

<xsd:enumeration value="100000" />

<xsd:enumeration value="201000" />

<xsd:enumeration value="401000" />

<xsd:enumeration value="402000" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="sts" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="stsL" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="s" type="xsd:decimal" minOccurs="0" />

<xsd:element name="st" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="rawData" type="xsd:anyType" minOccurs="0" maxOccurs="unbounded" />

<xsd:element name="processData" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="isShiftedStartEnd" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="isShiftedIntervals" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="isErrorEncountered" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="servicePointId" type="xsd:string" minOccurs="0" />

<xsd:element name="installationConstant" type="xsd:decimal" minOccurs="0" />

<xsd:element name="deviceId" type="xsd:string" minOccurs="0" />

<xsd:element name="logs" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="logsList" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="logsEntry" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="sequence" type="xsd:decimal" minOccurs="0" />

<xsd:element name="mo" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue1" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue2" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue3" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue4" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue5" type="xsd:string" minOccurs="0" />

<xsd:element name="logEntryType" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="toDos" />

<xsd:enumeration value="created" />

<xsd:enumeration value="statusTransitionError" />

<xsd:enumeration value="exception" />

<xsd:enumeration value="statusTransition" />

<xsd:enumeration value="system" />

<xsd:enumeration value="toDo" />

<xsd:enumeration value="userDetails" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="logDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="boStatus" type="xsd:string" minOccurs="0" />

<xsd:element name="description" type="xsd:string" minOccurs="0" />

<xsd:element name="user" type="xsd:string" minOccurs="0" />

<xsd:element name="logMessage" type="xsd:string" minOccurs="0" />

<xsd:element name="characteristicType" type="xsd:string" minOccurs="0" />

<xsd:element name="characteristicValue" type="xsd:string" minOccurs="0" />

<xsd:element name="adhocValue" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue1" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue2" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue3" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue4" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue5" type="xsd:string" minOccurs="0" />

<xsd:element name="messageCategory" type="xsd:decimal" minOccurs="0" />

<xsd:element name="messageNumber" type="xsd:decimal" minOccurs="0" />

<xsd:element name="messageParm1" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm2" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm3" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm4" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm5" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm6" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm7" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm8" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm9" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="deviceEventTypes" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="deviceEventTypesList" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="deviceEventType" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="boStatus" type="xsd:string" minOccurs="0" />

<xsd:element name="statusReason" type="xsd:string" minOccurs="0" />

<xsd:element name="bo" type="xsd:string" />

<xsd:element name="creationDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="boStatusDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="isTraceOn" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="isIntervalDateTimePopulated">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="isReprocessPerformed" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="serviceProvider" type="xsd:string" minOccurs="0" />

<xsd:element name="serviceProviderExternalId" type="xsd:string" minOccurs="0" />

<xsd:element name="fromDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="toDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="timeZone" type="xsd:string" minOccurs="0" />

<xsd:element name="isAutomatedRetry" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="retryUntilDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="version" type="xsd:decimal" minOccurs="0" />

</xsd:sequence>

<xsd:attribute name="dateTimeTagFormat" type="xsd:string" fixed="xsd" use="required" />

<xsd:attribute name="transactionType">

<xsd:simpleType>

<xsd:restriction base="xsd:token">

<xsd:enumeration value="RWOV" />

<xsd:enumeration value="FADD" />

<xsd:enumeration value="FUPD" />

<xsd:enumeration value="DEL" />

<xsd:enumeration value="UPD" />

<xsd:enumeration value="ADD" />

<xsd:enumeration value="READ" />

<xsd:enumeration value="REPL" />

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Initial Measurement Data XML Format

This section describes the XML format used for inbound initial measurement data. This includes interval and scalar examples, descriptions of the individual XML elements, and the initial measurement data XML schema based on the D1-IMDSeeder business object.

Example - Interval Initial Measurement Data

<IMD-IMPORT>

<serviceProvider>HEADEND-1</serviceProvider>

<serviceProviderExternalId>MDCS-1</serviceProviderExternalId>

<preVEE>

</simdId>

<dvcIdN>037090184721</dvcIdN>

<mcId>135914144111</mcId>

<mcIdN>123</mcIdN>

<externalId>IMD1234567</externalId>

<uom>KWH</uom>

<stDt>2009-01-02-00.00.00</stDt>

</stQty>

<enDt>2009-01-03-00.00.00</enDt>

</enQty>

<imdType>D1IL</imdType>

<mcIS>D1IN</mcIS>

<inShift>N</inShift>

<mcm>1.0</mcm>

</nd>

<tz>USPACIFIC</tz>

<spi>3600</spi>

</ccond>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

<msrs>

<mL>

<s>1</s>

<q>1.6</q>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</mL>

<mL>

<s>2</s>

<q>1.57</q>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</mL>

<mL>

<s>3</s>

<q>0.0</q>

<sts>

<stsL>

<s>1</s>

<st>MISSING</st>

<s>2</s>

<st>OUTAGE</st>

</stsL>

</sts>

</mL>

<mL>

<s>4</s>

<q>0.0</q>

<sts>

<stsL>

<s>1</s>

<st>MISSING</st>

<s>2</s>

<st>OUTAGE</st>

</stsL>

</sts>

</mL>

<mL>

<s>5</s>

<q>1.0</q>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</mL>

<mL>

<s>6</s>

<q>1.45</q>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</mL>

...

</msrs>

</preVEE>

</IMD-IMPORT>

Example - Scalar Initial Measurement Data

<IMD-IMPORT>

<serviceProvider>HEADEND-2</serviceProvider>

<serviceProviderExternalId>MDCS-2</serviceProviderExternalId>

<preVEE>

<dvcIdN>037090184721</dvcIdN>

<mcId>327604570580</mcId>

<mcIdN>123</mcIdN>

<externalId>IMD7654321</externalId>

<uom>KWH</uom>

<stDt>2009-01-31-11.25.00</stDt>

</stQty>

<enDt>2009-02-28-13.13.00</enDt>

<enQty>110.00</enQty>

<imdType>D1IL</imdType>

<mcIS>D1SC</mcIS>

<inShift>N</inShift>

<mcm>1.0</mcm>

<nd>5</nd>

<tz>USPACIFIC</tz>

</ccond>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</preVEE>

<processData>

</isShiftStartEnd>

</isShiftedIntervals>

</isErrorEncountered>

</servicePointId>

</installationConstant>

</deviceId>

</logs>

<deviceEventTypes>

<deviceEventTypesList>

<deviceEventType>BROKEN</deviceEventType>

</deviceEventTypesList>

</deviceEventTypes>

</processData>

</IMD-IMPORT>

Element Descriptions - Initial Measurement Data

The table below provides descriptions of the elements used in the initial measurement data XML format.

Element

Description

<{SERVICE_NAME}>

Root element containing an initial measurement. This element should match the name of the inbound service used to import the usage.

<serviceProvider>

Name of the head-end system (defined as a service provider) in MDM

<serviceProviderExternalId>

External ID of the head-end system.

<preVEE>

Element containing Pre VEE measurement data

<simdId>

The ID of a specific initial measurement

<dvcIdN>

Device Identifier Number, e.g. a Serial Number. The "type" of device identifier that the head-end system understands is configured within MDM - and so can differ per head-end.

<mcId>

Measuring Component ID

<mcIdN>

Measuring Component Identifier Number. Populated with channel ID. The "type" of measuring component identifier that the head-end system understands is configured within MDM

<externalId>

File name of ID of the XML document containing the measurement data

<uom>

Unit of Measure (Optional)

<stDt>

Start Date/Time. Required for interval measurement data. Optional for scalar measurement data. Must be in the following format:

YYYY-MM-DD-HH.MM.SS

Example:2008-12-31-00.30.00

<stQty>

Start Reading. Optional.

<enDt>

End Date/Time. Required.

Must be in the following format:

YYYY-MM-DD-HH.MM.SS

Example:2008-12-31-00.30.00

<enQty>

End Reading. Required for scalar measurements.

<imdType>

Initial measurement data type. Valid values include:

•

D1IL (Initial Load)

•

D1MO (Manual)

•

D1ES (Estimation)

Defaults to D1IL (Initial Load) if not supplied.

<mcIS>

Interval Scalar flag. Indicates if the data is for an interval or scalar measuring component.

<inShift>

Incoming Data Shift flag. Indicates if the device is DST aware.

<mcm>

Meter multiplier.

<nd>

Number of Dials

<tz>

Time Zone

<spi>

Seconds-per-interval

<ccond>

Measurement condition

<sts>

Element containing status code information for entire measurement.

<stsL>

List of head-end system status codes for the entire measurement

<s>

Sequence

<st>

Head-end status codes applicable to the entire set of data.

<msrs>

Element containing measurement data

<mL>

Element containing an individual interval measurements. Used for interval measurement data only.

<s>

Sequence of the interval measurement

<dt>

Date and time of the interval measurement. Optional.

<q>

Quantity of the interval measurement

<ue>

Used-Edited flag. Indicates if the interval measurement has been manually edited

<fc>

Final Condition code for the interval measurement. Optional.

<sts>

Element containing lists of status codes for each interval measurement

<stsL>

Element containing a sequence/status pairing for each interval measurement

<s>

Sequence of the status code for this interval measurement.

<st>

Head-end status code of the interval measurement.

<processData>

Element containing processing-related data.

</deviceEventTypes>

Element containing one or more lists of device event types (used to capture Reader Remarks for scalar measurements)

<deviceEventTypesList>

Element containing one or more device event types (used to capture Reader Remarks for scalar measurements)

<deviceEventType>

A device event type code that represents a Reader Remark (used with scalar measurements)

Schema - IMD Seeder (D1-IMDSeeder) Business Object

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ouaf="http://ouaf.oracle.com/" targetNamespace="http://oracle.com/D1-InitialLoadIMD.xsd" elementFormDefault="qualified">

<xsd:import namespace="http://ouaf.oracle.com/" />

<xsd:element name="D1-InitialLoadIMD">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="initialMeasurementDataId" type="xsd:string" minOccurs="0" />

<xsd:element name="preVEE" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="simdId" type="xsd:string" minOccurs="0" />

<xsd:element name="dvcIdN" type="xsd:string" minOccurs="0" />

<xsd:element name="mcId" type="xsd:string" minOccurs="0" />

<xsd:element name="mcIdN" type="xsd:string" minOccurs="0" />

<xsd:element name="externalId" type="xsd:string" minOccurs="0" />

<xsd:element name="uom" type="xsd:string" minOccurs="0" />

<xsd:element name="externalUOM" type="xsd:string" minOccurs="0" />

<xsd:element name="stDt" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="stQty" type="xsd:decimal" minOccurs="0" />

<xsd:element name="enDt" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="enQty" type="xsd:decimal" minOccurs="0" />

<xsd:element name="imdType" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="estimation" />

<xsd:enumeration value="imdSeeder" />

<xsd:enumeration value="initialLoad" />

<xsd:enumeration value="manual" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="inShift" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="notShifted" />

<xsd:enumeration value="shifted" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="mcm" type="xsd:decimal" minOccurs="0" />

<xsd:element name="nd" type="xsd:decimal" minOccurs="0" />

<xsd:element name="tz" type="xsd:string" minOccurs="0" />

<xsd:element name="spi" type="xsd:int" minOccurs="0" />

<xsd:element name="ccond" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="301000" />

<xsd:enumeration value="901000" />

<xsd:enumeration value="501000" />

<xsd:enumeration value="101000" />

<xsd:enumeration value="100000" />

<xsd:enumeration value="201000" />

<xsd:enumeration value="401000" />

<xsd:enumeration value="402000" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="sts" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="stsL" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="s" type="xsd:decimal" minOccurs="0" />

<xsd:element name="st" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="msrs" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="mL" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="s" type="xsd:decimal" minOccurs="0" />

<xsd:element name="dt" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="q" type="xsd:decimal" minOccurs="0" />

<xsd:element name="ue" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="userEdited" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="fc" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="301000" />

<xsd:enumeration value="901000" />

<xsd:enumeration value="501000" />

<xsd:enumeration value="101000" />

<xsd:enumeration value="100000" />

<xsd:enumeration value="201000" />

<xsd:enumeration value="401000" />

<xsd:enumeration value="402000" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="sts" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="stsL" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="s" type="xsd:decimal" minOccurs="0" />

<xsd:element name="st" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="rawData" type="xsd:anyType" minOccurs="0" maxOccurs="unbounded" />

<xsd:element name="processData" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="isShiftedStartEnd" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="isShiftedIntervals" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="isErrorEncountered" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="servicePointId" type="xsd:string" minOccurs="0" />

<xsd:element name="installationConstant" type="xsd:decimal" minOccurs="0" />

<xsd:element name="deviceId" type="xsd:string" minOccurs="0" />

<xsd:element name="logs" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="logsList" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="logsEntry" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="sequence" type="xsd:decimal" minOccurs="0" />

<xsd:element name="mo" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue1" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue2" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue3" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue4" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue5" type="xsd:string" minOccurs="0" />

<xsd:element name="logEntryType" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="toDos" />

<xsd:enumeration value="created" />

<xsd:enumeration value="statusTransitionError" />

<xsd:enumeration value="exception" />

<xsd:enumeration value="statusTransition" />

<xsd:enumeration value="system" />

<xsd:enumeration value="toDo" />

<xsd:enumeration value="userDetails" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="logDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="boStatus" type="xsd:string" minOccurs="0" />

<xsd:element name="description" type="xsd:string" minOccurs="0" />

<xsd:element name="user" type="xsd:string" minOccurs="0" />

<xsd:element name="logMessage" type="xsd:string" minOccurs="0" />

<xsd:element name="characteristicType" type="xsd:string" minOccurs="0" />

<xsd:element name="characteristicValue" type="xsd:string" minOccurs="0" />

<xsd:element name="adhocValue" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue1" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue2" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue3" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue4" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue5" type="xsd:string" minOccurs="0" />

<xsd:element name="messageCategory" type="xsd:decimal" minOccurs="0" />

<xsd:element name="messageNumber" type="xsd:decimal" minOccurs="0" />

<xsd:element name="messageParm1" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm2" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm3" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm4" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm5" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm6" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm7" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm8" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm9" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="deviceEventTypes" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="deviceEventTypesList" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="deviceEventType" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="boStatus" type="xsd:string" minOccurs="0" />

<xsd:element name="statusReason" type="xsd:string" minOccurs="0" />

<xsd:element name="bo" type="xsd:string" />

<xsd:element name="creationDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="boStatusDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="isTraceOn" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="isIntervalDateTimePopulated">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="isReprocessPerformed" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="serviceProvider" type="xsd:string" minOccurs="0" />

<xsd:element name="serviceProviderExternalId" type="xsd:string" minOccurs="0" />

<xsd:element name="fromDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="toDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="timeZone" type="xsd:string" minOccurs="0" />

<xsd:element name="isAutomatedRetry" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="retryUntilDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="version" type="xsd:decimal" minOccurs="0" />

</xsd:sequence>

<xsd:attribute name="dateTimeTagFormat" type="xsd:string" fixed="xsd" use="required" />

<xsd:attribute name="transactionType">

<xsd:simpleType>

<xsd:restriction base="xsd:token">

<xsd:enumeration value="RWOV" />

<xsd:enumeration value="FADD" />

<xsd:enumeration value="FUPD" />

<xsd:enumeration value="DEL" />

<xsd:enumeration value="UPD" />

<xsd:enumeration value="ADD" />

<xsd:enumeration value="READ" />

<xsd:enumeration value="REPL" />

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Initial Measurement Data XML Format

This section describes the XML format used for inbound initial measurement data. This includes interval and scalar examples, descriptions of the individual XML elements, and the initial measurement data XML schema based on the D1-IMDSeeder business object.

Example - Interval Initial Measurement Data

<IMD-IMPORT>

<serviceProvider>HEADEND-1</serviceProvider>

<serviceProviderExternalId>MDCS-1</serviceProviderExternalId>

<preVEE>

</simdId>

<dvcIdN>037090184721</dvcIdN>

<mcId>135914144111</mcId>

<mcIdN>123</mcIdN>

<externalId>IMD1234567</externalId>

<uom>KWH</uom>

<stDt>2009-01-02-00.00.00</stDt>

</stQty>

<enDt>2009-01-03-00.00.00</enDt>

</enQty>

<imdType>D1IL</imdType>

<mcIS>D1IN</mcIS>

<inShift>N</inShift>

<mcm>1.0</mcm>

</nd>

<tz>USPACIFIC</tz>

<spi>3600</spi>

</ccond>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

<msrs>

<mL>

<s>1</s>

<q>1.6</q>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</mL>

<mL>

<s>2</s>

<q>1.57</q>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</mL>

<mL>

<s>3</s>

<q>0.0</q>

<sts>

<stsL>

<s>1</s>

<st>MISSING</st>

<s>2</s>

<st>OUTAGE</st>

</stsL>

</sts>

</mL>

<mL>

<s>4</s>

<q>0.0</q>

<sts>

<stsL>

<s>1</s>

<st>MISSING</st>

<s>2</s>

<st>OUTAGE</st>

</stsL>

</sts>

</mL>

<mL>

<s>5</s>

<q>1.0</q>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</mL>

<mL>

<s>6</s>

<q>1.45</q>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</mL>

...

</msrs>

</preVEE>

</IMD-IMPORT>

Example - Scalar Initial Measurement Data

<IMD-IMPORT>

<serviceProvider>HEADEND-2</serviceProvider>

<serviceProviderExternalId>MDCS-2</serviceProviderExternalId>

<preVEE>

<dvcIdN>037090184721</dvcIdN>

<mcId>327604570580</mcId>

<mcIdN>123</mcIdN>

<externalId>IMD7654321</externalId>

<uom>KWH</uom>

<stDt>2009-01-31-11.25.00</stDt>

</stQty>

<enDt>2009-02-28-13.13.00</enDt>

<enQty>110.00</enQty>

<imdType>D1IL</imdType>

<mcIS>D1SC</mcIS>

<inShift>N</inShift>

<mcm>1.0</mcm>

<nd>5</nd>

<tz>USPACIFIC</tz>

</ccond>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</preVEE>

<processData>

</isShiftStartEnd>

</isShiftedIntervals>

</isErrorEncountered>

</servicePointId>

</installationConstant>

</deviceId>

</logs>

<deviceEventTypes>

<deviceEventTypesList>

<deviceEventType>BROKEN</deviceEventType>

</deviceEventTypesList>

</deviceEventTypes>

</processData>

</IMD-IMPORT>

Element Descriptions - Initial Measurement Data

The table below provides descriptions of the elements used in the initial measurement data XML format.

Element

Description

<{SERVICE_NAME}>

Root element containing an initial measurement. This element should match the name of the inbound service used to import the usage.

<serviceProvider>

Name of the head-end system (defined as a service provider) in MDM

<serviceProviderExternalId>

External ID of the head-end system.

<preVEE>

Element containing Pre VEE measurement data

<simdId>

The ID of a specific initial measurement

<dvcIdN>

Device Identifier Number, e.g. a Serial Number. The "type" of device identifier that the head-end system understands is configured within MDM - and so can differ per head-end.

<mcId>

Measuring Component ID

<mcIdN>

Measuring Component Identifier Number. Populated with channel ID. The "type" of measuring component identifier that the head-end system understands is configured within MDM

<externalId>

File name of ID of the XML document containing the measurement data

<uom>

Unit of Measure (Optional)

<stDt>

Start Date/Time. Required for interval measurement data. Optional for scalar measurement data. Must be in the following format:

YYYY-MM-DD-HH.MM.SS

Example:2008-12-31-00.30.00

<stQty>

Start Reading. Optional.

<enDt>

End Date/Time. Required.

Must be in the following format:

YYYY-MM-DD-HH.MM.SS

Example:2008-12-31-00.30.00

<enQty>

End Reading. Required for scalar measurements.

<imdType>

Initial measurement data type. Valid values include:

•

D1IL (Initial Load)

•

D1MO (Manual)

•

D1ES (Estimation)

Defaults to D1IL (Initial Load) if not supplied.

<mcIS>

Interval Scalar flag. Indicates if the data is for an interval or scalar measuring component.

<inShift>

Incoming Data Shift flag. Indicates if the device is DST aware.

<mcm>

Meter multiplier.

<nd>

Number of Dials

<tz>

Time Zone

<spi>

Seconds-per-interval

<ccond>

Measurement condition

<sts>

Element containing status code information for entire measurement.

<stsL>

List of head-end system status codes for the entire measurement

<s>

Sequence

<st>

Head-end status codes applicable to the entire set of data.

<msrs>

Element containing measurement data

<mL>

Element containing an individual interval measurements. Used for interval measurement data only.

<s>

Sequence of the interval measurement

<dt>

Date and time of the interval measurement. Optional.

<q>

Quantity of the interval measurement

<ue>

Used-Edited flag. Indicates if the interval measurement has been manually edited

<fc>

Final Condition code for the interval measurement. Optional.

<sts>

Element containing lists of status codes for each interval measurement

<stsL>

Element containing a sequence/status pairing for each interval measurement

<s>

Sequence of the status code for this interval measurement.

<st>

Head-end status code of the interval measurement.

<processData>

Element containing processing-related data.

</deviceEventTypes>

Element containing one or more lists of device event types (used to capture Reader Remarks for scalar measurements)

<deviceEventTypesList>

Element containing one or more device event types (used to capture Reader Remarks for scalar measurements)

<deviceEventType>

A device event type code that represents a Reader Remark (used with scalar measurements)

Schema - IMD Seeder (D1-IMDSeeder) Business Object

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ouaf="http://ouaf.oracle.com/" targetNamespace="http://oracle.com/D1-InitialLoadIMD.xsd" elementFormDefault="qualified">

<xsd:import namespace="http://ouaf.oracle.com/" />

<xsd:element name="D1-InitialLoadIMD">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="initialMeasurementDataId" type="xsd:string" minOccurs="0" />

<xsd:element name="preVEE" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="simdId" type="xsd:string" minOccurs="0" />

<xsd:element name="dvcIdN" type="xsd:string" minOccurs="0" />

<xsd:element name="mcId" type="xsd:string" minOccurs="0" />

<xsd:element name="mcIdN" type="xsd:string" minOccurs="0" />

<xsd:element name="externalId" type="xsd:string" minOccurs="0" />

<xsd:element name="uom" type="xsd:string" minOccurs="0" />

<xsd:element name="externalUOM" type="xsd:string" minOccurs="0" />

<xsd:element name="stDt" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="stQty" type="xsd:decimal" minOccurs="0" />

<xsd:element name="enDt" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="enQty" type="xsd:decimal" minOccurs="0" />

<xsd:element name="imdType" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="estimation" />

<xsd:enumeration value="imdSeeder" />

<xsd:enumeration value="initialLoad" />

<xsd:enumeration value="manual" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="inShift" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="notShifted" />

<xsd:enumeration value="shifted" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="mcm" type="xsd:decimal" minOccurs="0" />

<xsd:element name="nd" type="xsd:decimal" minOccurs="0" />

<xsd:element name="tz" type="xsd:string" minOccurs="0" />

<xsd:element name="spi" type="xsd:int" minOccurs="0" />

<xsd:element name="ccond" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="301000" />

<xsd:enumeration value="901000" />

<xsd:enumeration value="501000" />

<xsd:enumeration value="101000" />

<xsd:enumeration value="100000" />

<xsd:enumeration value="201000" />

<xsd:enumeration value="401000" />

<xsd:enumeration value="402000" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="sts" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="stsL" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="s" type="xsd:decimal" minOccurs="0" />

<xsd:element name="st" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="msrs" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="mL" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="s" type="xsd:decimal" minOccurs="0" />

<xsd:element name="dt" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="q" type="xsd:decimal" minOccurs="0" />

<xsd:element name="ue" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="userEdited" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="fc" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="301000" />

<xsd:enumeration value="901000" />

<xsd:enumeration value="501000" />

<xsd:enumeration value="101000" />

<xsd:enumeration value="100000" />

<xsd:enumeration value="201000" />

<xsd:enumeration value="401000" />

<xsd:enumeration value="402000" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="sts" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="stsL" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="s" type="xsd:decimal" minOccurs="0" />

<xsd:element name="st" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="rawData" type="xsd:anyType" minOccurs="0" maxOccurs="unbounded" />

<xsd:element name="processData" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="isShiftedStartEnd" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="isShiftedIntervals" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="isErrorEncountered" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="servicePointId" type="xsd:string" minOccurs="0" />

<xsd:element name="installationConstant" type="xsd:decimal" minOccurs="0" />

<xsd:element name="deviceId" type="xsd:string" minOccurs="0" />

<xsd:element name="logs" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="logsList" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="logsEntry" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="sequence" type="xsd:decimal" minOccurs="0" />

<xsd:element name="mo" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue1" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue2" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue3" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue4" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue5" type="xsd:string" minOccurs="0" />

<xsd:element name="logEntryType" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="toDos" />

<xsd:enumeration value="created" />

<xsd:enumeration value="statusTransitionError" />

<xsd:enumeration value="exception" />

<xsd:enumeration value="statusTransition" />

<xsd:enumeration value="system" />

<xsd:enumeration value="toDo" />

<xsd:enumeration value="userDetails" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="logDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="boStatus" type="xsd:string" minOccurs="0" />

<xsd:element name="description" type="xsd:string" minOccurs="0" />

<xsd:element name="user" type="xsd:string" minOccurs="0" />

<xsd:element name="logMessage" type="xsd:string" minOccurs="0" />

<xsd:element name="characteristicType" type="xsd:string" minOccurs="0" />

<xsd:element name="characteristicValue" type="xsd:string" minOccurs="0" />

<xsd:element name="adhocValue" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue1" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue2" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue3" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue4" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue5" type="xsd:string" minOccurs="0" />

<xsd:element name="messageCategory" type="xsd:decimal" minOccurs="0" />

<xsd:element name="messageNumber" type="xsd:decimal" minOccurs="0" />

<xsd:element name="messageParm1" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm2" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm3" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm4" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm5" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm6" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm7" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm8" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm9" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="deviceEventTypes" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="deviceEventTypesList" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="deviceEventType" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="boStatus" type="xsd:string" minOccurs="0" />

<xsd:element name="statusReason" type="xsd:string" minOccurs="0" />

<xsd:element name="bo" type="xsd:string" />

<xsd:element name="creationDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="boStatusDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="isTraceOn" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="isIntervalDateTimePopulated">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="isReprocessPerformed" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="serviceProvider" type="xsd:string" minOccurs="0" />

<xsd:element name="serviceProviderExternalId" type="xsd:string" minOccurs="0" />

<xsd:element name="fromDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="toDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="timeZone" type="xsd:string" minOccurs="0" />

<xsd:element name="isAutomatedRetry" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="retryUntilDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="version" type="xsd:decimal" minOccurs="0" />

</xsd:sequence>

<xsd:attribute name="dateTimeTagFormat" type="xsd:string" fixed="xsd" use="required" />

<xsd:attribute name="transactionType">

<xsd:simpleType>

<xsd:restriction base="xsd:token">

<xsd:enumeration value="RWOV" />

<xsd:enumeration value="FADD" />

<xsd:enumeration value="FUPD" />

<xsd:enumeration value="DEL" />

<xsd:enumeration value="UPD" />

<xsd:enumeration value="ADD" />

<xsd:enumeration value="READ" />

<xsd:enumeration value="REPL" />

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Initial Measurement Data XML Format

This section describes the XML format used for inbound initial measurement data. This includes interval and scalar examples, descriptions of the individual XML elements, and the initial measurement data XML schema based on the D1-IMDSeeder business object.

Example - Interval Initial Measurement Data

<IMD-IMPORT>

<serviceProvider>HEADEND-1</serviceProvider>

<serviceProviderExternalId>MDCS-1</serviceProviderExternalId>

<preVEE>

</simdId>

<dvcIdN>037090184721</dvcIdN>

<mcId>135914144111</mcId>

<mcIdN>123</mcIdN>

<externalId>IMD1234567</externalId>

<uom>KWH</uom>

<stDt>2009-01-02-00.00.00</stDt>

</stQty>

<enDt>2009-01-03-00.00.00</enDt>

</enQty>

<imdType>D1IL</imdType>

<mcIS>D1IN</mcIS>

<inShift>N</inShift>

<mcm>1.0</mcm>

</nd>

<tz>USPACIFIC</tz>

<spi>3600</spi>

</ccond>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

<msrs>

<mL>

<s>1</s>

<q>1.6</q>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</mL>

<mL>

<s>2</s>

<q>1.57</q>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</mL>

<mL>

<s>3</s>

<q>0.0</q>

<sts>

<stsL>

<s>1</s>

<st>MISSING</st>

<s>2</s>

<st>OUTAGE</st>

</stsL>

</sts>

</mL>

<mL>

<s>4</s>

<q>0.0</q>

<sts>

<stsL>

<s>1</s>

<st>MISSING</st>

<s>2</s>

<st>OUTAGE</st>

</stsL>

</sts>

</mL>

<mL>

<s>5</s>

<q>1.0</q>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</mL>

<mL>

<s>6</s>

<q>1.45</q>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</mL>

...

</msrs>

</preVEE>

</IMD-IMPORT>

Example - Scalar Initial Measurement Data

<IMD-IMPORT>

<serviceProvider>HEADEND-2</serviceProvider>

<serviceProviderExternalId>MDCS-2</serviceProviderExternalId>

<preVEE>

<dvcIdN>037090184721</dvcIdN>

<mcId>327604570580</mcId>

<mcIdN>123</mcIdN>

<externalId>IMD7654321</externalId>

<uom>KWH</uom>

<stDt>2009-01-31-11.25.00</stDt>

</stQty>

<enDt>2009-02-28-13.13.00</enDt>

<enQty>110.00</enQty>

<imdType>D1IL</imdType>

<mcIS>D1SC</mcIS>

<inShift>N</inShift>

<mcm>1.0</mcm>

<nd>5</nd>

<tz>USPACIFIC</tz>

</ccond>

<sts>

<stsL>

<s>1</s>

<st>REGULAR</st>

</stsL>

</sts>

</preVEE>

<processData>

</isShiftStartEnd>

</isShiftedIntervals>

</isErrorEncountered>

</servicePointId>

</installationConstant>

</deviceId>

</logs>

<deviceEventTypes>

<deviceEventTypesList>

<deviceEventType>BROKEN</deviceEventType>

</deviceEventTypesList>

</deviceEventTypes>

</processData>

</IMD-IMPORT>

Element Descriptions - Initial Measurement Data

The table below provides descriptions of the elements used in the initial measurement data XML format.

Element

Description

<{SERVICE_NAME}>

Root element containing an initial measurement. This element should match the name of the inbound service used to import the usage.

<serviceProvider>

Name of the head-end system (defined as a service provider) in MDM

<serviceProviderExternalId>

External ID of the head-end system.

<preVEE>

Element containing Pre VEE measurement data

<simdId>

The ID of a specific initial measurement

<dvcIdN>

Device Identifier Number, e.g. a Serial Number. The "type" of device identifier that the head-end system understands is configured within MDM - and so can differ per head-end.

<mcId>

Measuring Component ID

<mcIdN>

Measuring Component Identifier Number. Populated with channel ID. The "type" of measuring component identifier that the head-end system understands is configured within MDM

<externalId>

File name of ID of the XML document containing the measurement data

<uom>

Unit of Measure (Optional)

<stDt>

Start Date/Time. Required for interval measurement data. Optional for scalar measurement data. Must be in the following format:

YYYY-MM-DD-HH.MM.SS

Example:2008-12-31-00.30.00

<stQty>

Start Reading. Optional.

<enDt>

End Date/Time. Required.

Must be in the following format:

YYYY-MM-DD-HH.MM.SS

Example:2008-12-31-00.30.00

<enQty>

End Reading. Required for scalar measurements.

<imdType>

Initial measurement data type. Valid values include:

•

D1IL (Initial Load)

•

D1MO (Manual)

•

D1ES (Estimation)

Defaults to D1IL (Initial Load) if not supplied.

<mcIS>

Interval Scalar flag. Indicates if the data is for an interval or scalar measuring component.

<inShift>

Incoming Data Shift flag. Indicates if the device is DST aware.

<mcm>

Meter multiplier.

<nd>

Number of Dials

<tz>

Time Zone

<spi>

Seconds-per-interval

<ccond>

Measurement condition

<sts>

Element containing status code information for entire measurement.

<stsL>

List of head-end system status codes for the entire measurement

<s>

Sequence

<st>

Head-end status codes applicable to the entire set of data.

<msrs>

Element containing measurement data

<mL>

Element containing an individual interval measurements. Used for interval measurement data only.

<s>

Sequence of the interval measurement

<dt>

Date and time of the interval measurement. Optional.

<q>

Quantity of the interval measurement

<ue>

Used-Edited flag. Indicates if the interval measurement has been manually edited

<fc>

Final Condition code for the interval measurement. Optional.

<sts>

Element containing lists of status codes for each interval measurement

<stsL>

Element containing a sequence/status pairing for each interval measurement

<s>

Sequence of the status code for this interval measurement.

<st>

Head-end status code of the interval measurement.

<processData>

Element containing processing-related data.

</deviceEventTypes>

Element containing one or more lists of device event types (used to capture Reader Remarks for scalar measurements)

<deviceEventTypesList>

Element containing one or more device event types (used to capture Reader Remarks for scalar measurements)

<deviceEventType>

A device event type code that represents a Reader Remark (used with scalar measurements)

Schema - IMD Seeder (D1-IMDSeeder) Business Object

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ouaf="http://ouaf.oracle.com/" targetNamespace="http://oracle.com/D1-InitialLoadIMD.xsd" elementFormDefault="qualified">

<xsd:import namespace="http://ouaf.oracle.com/" />

<xsd:element name="D1-InitialLoadIMD">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="initialMeasurementDataId" type="xsd:string" minOccurs="0" />

<xsd:element name="preVEE" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="simdId" type="xsd:string" minOccurs="0" />

<xsd:element name="dvcIdN" type="xsd:string" minOccurs="0" />

<xsd:element name="mcId" type="xsd:string" minOccurs="0" />

<xsd:element name="mcIdN" type="xsd:string" minOccurs="0" />

<xsd:element name="externalId" type="xsd:string" minOccurs="0" />

<xsd:element name="uom" type="xsd:string" minOccurs="0" />

<xsd:element name="externalUOM" type="xsd:string" minOccurs="0" />

<xsd:element name="stDt" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="stQty" type="xsd:decimal" minOccurs="0" />

<xsd:element name="enDt" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="enQty" type="xsd:decimal" minOccurs="0" />

<xsd:element name="imdType" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="estimation" />

<xsd:enumeration value="imdSeeder" />

<xsd:enumeration value="initialLoad" />

<xsd:enumeration value="manual" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="inShift" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="notShifted" />

<xsd:enumeration value="shifted" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="mcm" type="xsd:decimal" minOccurs="0" />

<xsd:element name="nd" type="xsd:decimal" minOccurs="0" />

<xsd:element name="tz" type="xsd:string" minOccurs="0" />

<xsd:element name="spi" type="xsd:int" minOccurs="0" />

<xsd:element name="ccond" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="301000" />

<xsd:enumeration value="901000" />

<xsd:enumeration value="501000" />

<xsd:enumeration value="101000" />

<xsd:enumeration value="100000" />

<xsd:enumeration value="201000" />

<xsd:enumeration value="401000" />

<xsd:enumeration value="402000" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="sts" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="stsL" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="s" type="xsd:decimal" minOccurs="0" />

<xsd:element name="st" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="msrs" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="mL" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="s" type="xsd:decimal" minOccurs="0" />

<xsd:element name="dt" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="q" type="xsd:decimal" minOccurs="0" />

<xsd:element name="ue" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="userEdited" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="fc" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="301000" />

<xsd:enumeration value="901000" />

<xsd:enumeration value="501000" />

<xsd:enumeration value="101000" />

<xsd:enumeration value="100000" />

<xsd:enumeration value="201000" />

<xsd:enumeration value="401000" />

<xsd:enumeration value="402000" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="sts" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="stsL" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="s" type="xsd:decimal" minOccurs="0" />

<xsd:element name="st" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="rawData" type="xsd:anyType" minOccurs="0" maxOccurs="unbounded" />

<xsd:element name="processData" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="isShiftedStartEnd" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="isShiftedIntervals" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="isErrorEncountered" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="servicePointId" type="xsd:string" minOccurs="0" />

<xsd:element name="installationConstant" type="xsd:decimal" minOccurs="0" />

<xsd:element name="deviceId" type="xsd:string" minOccurs="0" />

<xsd:element name="logs" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="logsList" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="logsEntry" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="sequence" type="xsd:decimal" minOccurs="0" />

<xsd:element name="mo" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue1" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue2" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue3" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue4" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue5" type="xsd:string" minOccurs="0" />

<xsd:element name="logEntryType" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="toDos" />

<xsd:enumeration value="created" />

<xsd:enumeration value="statusTransitionError" />

<xsd:enumeration value="exception" />

<xsd:enumeration value="statusTransition" />

<xsd:enumeration value="system" />

<xsd:enumeration value="toDo" />

<xsd:enumeration value="userDetails" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="logDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="boStatus" type="xsd:string" minOccurs="0" />

<xsd:element name="description" type="xsd:string" minOccurs="0" />

<xsd:element name="user" type="xsd:string" minOccurs="0" />

<xsd:element name="logMessage" type="xsd:string" minOccurs="0" />

<xsd:element name="characteristicType" type="xsd:string" minOccurs="0" />

<xsd:element name="characteristicValue" type="xsd:string" minOccurs="0" />

<xsd:element name="adhocValue" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue1" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue2" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue3" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue4" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue5" type="xsd:string" minOccurs="0" />

<xsd:element name="messageCategory" type="xsd:decimal" minOccurs="0" />

<xsd:element name="messageNumber" type="xsd:decimal" minOccurs="0" />

<xsd:element name="messageParm1" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm2" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm3" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm4" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm5" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm6" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm7" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm8" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm9" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="deviceEventTypes" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="deviceEventTypesList" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="deviceEventType" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="boStatus" type="xsd:string" minOccurs="0" />

<xsd:element name="statusReason" type="xsd:string" minOccurs="0" />

<xsd:element name="bo" type="xsd:string" />

<xsd:element name="creationDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="boStatusDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="isTraceOn" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="isIntervalDateTimePopulated">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="isReprocessPerformed" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="serviceProvider" type="xsd:string" minOccurs="0" />

<xsd:element name="serviceProviderExternalId" type="xsd:string" minOccurs="0" />

<xsd:element name="fromDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="toDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="timeZone" type="xsd:string" minOccurs="0" />

<xsd:element name="isAutomatedRetry" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="retryUntilDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="version" type="xsd:decimal" minOccurs="0" />

</xsd:sequence>

<xsd:attribute name="dateTimeTagFormat" type="xsd:string" fixed="xsd" use="required" />

<xsd:attribute name="transactionType">

<xsd:simpleType>

<xsd:restriction base="xsd:token">

<xsd:enumeration value="RWOV" />

<xsd:enumeration value="FADD" />

<xsd:enumeration value="FUPD" />

<xsd:enumeration value="DEL" />

<xsd:enumeration value="UPD" />

<xsd:enumeration value="ADD" />

<xsd:enumeration value="READ" />

<xsd:enumeration value="REPL" />

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Device Event XML Format

This section describes the XML format used for inbound device events. This includes an example, descriptions of the individual XML elements, and the device event XML schema based on the D1-DeviceEventSeeder business object.

Example - Device Event

<D1-DeviceEventSeeder>

<externalSenderId>L+G</externalSenderId>

<deviceIdentifierNumber>GD_LL_SN100</deviceIdentifierNumber>

<externalEventName>GD_LL_TAMPER_INDICATION</externalEventName>

<rawEventInformation>D~Meter~GD_LL_SN100~GD_LL_ELECTRIC~1342395718~3~GD_HeadEnd_Power_Off~2010-09-09T13:11:41.0000000-05:00~Alert~Tamper indication on serial number GD_LL_SN100.~2010-09-09T13:11:41.0000000-05:00</rawEventInformation>

<eventDateTime>2010-09-09-13.11.41</eventDateTime>

<externalSourceIdentifier>EVENT_test.lg</externalSourceIdentifier>

<eventInformation>

<externalEventCategory>3</externalEventCategory>

<externalEventSeverity>Alert</externalEventSeverity>

<externalDeviceType>Meter</externalDeviceType>

<externalServiceLocationId>GD_LL_ELECTRIC</externalServiceLocationId>

<externalCommunicationModuleIdentifier>1342395718</externalCommunicationModuleIdentifier>

<externalStatusValue>Tamper indication on serial number GD_LL_SN100.</externalStatusValue>

<externalStatusDateTime>2010-09-09-13.11.41</externalStatusDateTime>

</eventInformation>

</D1-DeviceEventSeeder>

Element Descriptions - Device Events

The table below provides descriptions of the elements used in the device event XML format.

Element

Description

<{SERVICE_NAME}>

Root element containing a device event. This element should match the name of the inbound service used to import device events.

<externalSenderId>

Id of the external system. Used to identify the head-end system from which the event is being sent.

<deviceIdentifierNumber>

The identifier number of the device that experienced the event.

<externalEventName>

The name of the event as defined by the external system. This will be mapped to a standard name via a device mapping business object.

<rawEventInformation>

A string containing information about the event from the external system.

<eventDateTime>

The date and time of the event.

<externalSourceIdentifier>

The name of the file containing the device event.

<eventInformation>

Element containing specific information about the event

<externalEventCategory>

The event category as defined by the external system.

<externalEventSeverity>

The event severity as defined by the external system.

<externalDeviceType>

The device type as defined by the external system. Can be one of the following:

•

Meter

•

Collector

•

Router

<externalServiceLocationId>

The service location for the event defined by the external system.

<externalCommunicationModuleIdentifier>

The identifier for the communication module associated with the device.

<externalStatusValue>

Optional information related to the event.

<externalStatusDateTime>

Date and time at which optional information (specified in the <externalStatusValue> element was recorded.

Schema - Device Event Seeder (D1-DeviceEventSeeder) Business Object

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ouaf="http://ouaf.oracle.com/" targetNamespace="http://oracle.com/D1-DeviceEventSeeder.xsd" elementFormDefault="qualified">

<xsd:import namespace="http://ouaf.oracle.com/" />

<xsd:element name="D1-DeviceEventSeeder">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="deviceEventId" type="xsd:string" minOccurs="0" />

<xsd:element name="bo" type="xsd:string" minOccurs="0" />

<xsd:element name="boStatus" type="xsd:string" minOccurs="0" />

<xsd:element name="sender" type="xsd:string" minOccurs="0" />

<xsd:element name="externalSenderId" type="xsd:string" minOccurs="0" />

<xsd:element name="deviceEventType" type="xsd:string" minOccurs="0" />

<xsd:element name="externalEventName" type="xsd:string" minOccurs="0" />

<xsd:element name="eventDateTime" type="xsd:dateTime" />

<xsd:element name="eventEndDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="deviceId" type="xsd:string" minOccurs="0" />

<xsd:element name="creationDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="statusUpdateDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="statusReason" type="xsd:string" minOccurs="0" />

<xsd:element name="rawEventInformation" type="xsd:anyType" minOccurs="0" maxOccurs="unbounded" />

<xsd:element name="externalSourceIdentifier" type="xsd:string" minOccurs="0" />

<xsd:element name="eventInformation" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="externalEventIdentifier" type="xsd:string" minOccurs="0" />

<xsd:element name="externalEventCategory" type="xsd:string" minOccurs="0" />

<xsd:element name="externalEventSeverity" type="xsd:string" minOccurs="0" />

<xsd:element name="externalDeviceType" type="xsd:string" minOccurs="0" />

<xsd:element name="externalServiceLocationId" type="xsd:string" minOccurs="0" />

<xsd:element name="externalCommunicationModuleIdentifier" type="xsd:string" minOccurs="0" />

<xsd:element name="externalGatewayIdentifier" type="xsd:string" minOccurs="0" />

<xsd:element name="externalStatusValue" type="xsd:string" minOccurs="0" />

<xsd:element name="externalStatusDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="externalCommandId" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="version" type="xsd:decimal" minOccurs="0" />

<xsd:element name="deviceIdentifierNumber" type="xsd:string" minOccurs="0" />

<xsd:element name="newDeviceEvent" type="xsd:string" minOccurs="0" />

<xsd:element name="processData" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="errorEncountered" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="dateTimesInStandard" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="logs" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="logsList" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="logsEntry" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="sequence" type="xsd:decimal" minOccurs="0" />

<xsd:element name="mo" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue1" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue2" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue3" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue4" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue5" type="xsd:string" minOccurs="0" />

<xsd:element name="logEntryType" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="toDos" />

<xsd:enumeration value="created" />

<xsd:enumeration value="statusTransitionError" />

<xsd:enumeration value="exception" />

<xsd:enumeration value="statusTransition" />

<xsd:enumeration value="system" />

<xsd:enumeration value="toDo" />

<xsd:enumeration value="userDetails" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="logDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="boStatus" type="xsd:string" minOccurs="0" />

<xsd:element name="description" type="xsd:string" minOccurs="0" />

<xsd:element name="user" type="xsd:string" minOccurs="0" />

<xsd:element name="logMessage" type="xsd:string" minOccurs="0" />

<xsd:element name="characteristicType" type="xsd:string" minOccurs="0" />

<xsd:element name="characteristicValue" type="xsd:string" minOccurs="0" />

<xsd:element name="adhocValue" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue1" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue2" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue3" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue4" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue5" type="xsd:string" minOccurs="0" />

<xsd:element name="messageCategory" type="xsd:decimal" minOccurs="0" />

<xsd:element name="messageNumber" type="xsd:decimal" minOccurs="0" />

<xsd:element name="messageParm1" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm2" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm3" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm4" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm5" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm6" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm7" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm8" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm9" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

<xsd:attribute name="dateTimeTagFormat" type="xsd:string" fixed="xsd" use="required" />

<xsd:attribute name="transactionType">

<xsd:simpleType>

<xsd:restriction base="xsd:token">

<xsd:enumeration value="RWOV" />

<xsd:enumeration value="FADD" />

<xsd:enumeration value="FUPD" />

<xsd:enumeration value="DEL" />

<xsd:enumeration value="UPD" />

<xsd:enumeration value="ADD" />

<xsd:enumeration value="READ" />

<xsd:enumeration value="REPL" />

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Device Event XML Format

This section describes the XML format used for inbound device events. This includes an example, descriptions of the individual XML elements, and the device event XML schema based on the D1-DeviceEventSeeder business object.

Example - Device Event

<D1-DeviceEventSeeder>

<externalSenderId>L+G</externalSenderId>

<deviceIdentifierNumber>GD_LL_SN100</deviceIdentifierNumber>

<externalEventName>GD_LL_TAMPER_INDICATION</externalEventName>

<rawEventInformation>D~Meter~GD_LL_SN100~GD_LL_ELECTRIC~1342395718~3~GD_HeadEnd_Power_Off~2010-09-09T13:11:41.0000000-05:00~Alert~Tamper indication on serial number GD_LL_SN100.~2010-09-09T13:11:41.0000000-05:00</rawEventInformation>

<eventDateTime>2010-09-09-13.11.41</eventDateTime>

<externalSourceIdentifier>EVENT_test.lg</externalSourceIdentifier>

<eventInformation>

<externalEventCategory>3</externalEventCategory>

<externalEventSeverity>Alert</externalEventSeverity>

<externalDeviceType>Meter</externalDeviceType>

<externalServiceLocationId>GD_LL_ELECTRIC</externalServiceLocationId>

<externalCommunicationModuleIdentifier>1342395718</externalCommunicationModuleIdentifier>

<externalStatusValue>Tamper indication on serial number GD_LL_SN100.</externalStatusValue>

<externalStatusDateTime>2010-09-09-13.11.41</externalStatusDateTime>

</eventInformation>

</D1-DeviceEventSeeder>

Element Descriptions - Device Events

The table below provides descriptions of the elements used in the device event XML format.

Element

Description

<{SERVICE_NAME}>

Root element containing a device event. This element should match the name of the inbound service used to import device events.

<externalSenderId>

Id of the external system. Used to identify the head-end system from which the event is being sent.

<deviceIdentifierNumber>

The identifier number of the device that experienced the event.

<externalEventName>

The name of the event as defined by the external system. This will be mapped to a standard name via a device mapping business object.

<rawEventInformation>

A string containing information about the event from the external system.

<eventDateTime>

The date and time of the event.

<externalSourceIdentifier>

The name of the file containing the device event.

<eventInformation>

Element containing specific information about the event

<externalEventCategory>

The event category as defined by the external system.

<externalEventSeverity>

The event severity as defined by the external system.

<externalDeviceType>

The device type as defined by the external system. Can be one of the following:

•

Meter

•

Collector

•

Router

<externalServiceLocationId>

The service location for the event defined by the external system.

<externalCommunicationModuleIdentifier>

The identifier for the communication module associated with the device.

<externalStatusValue>

Optional information related to the event.

<externalStatusDateTime>

Date and time at which optional information (specified in the <externalStatusValue> element was recorded.

Schema - Device Event Seeder (D1-DeviceEventSeeder) Business Object

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ouaf="http://ouaf.oracle.com/" targetNamespace="http://oracle.com/D1-DeviceEventSeeder.xsd" elementFormDefault="qualified">

<xsd:import namespace="http://ouaf.oracle.com/" />

<xsd:element name="D1-DeviceEventSeeder">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="deviceEventId" type="xsd:string" minOccurs="0" />

<xsd:element name="bo" type="xsd:string" minOccurs="0" />

<xsd:element name="boStatus" type="xsd:string" minOccurs="0" />

<xsd:element name="sender" type="xsd:string" minOccurs="0" />

<xsd:element name="externalSenderId" type="xsd:string" minOccurs="0" />

<xsd:element name="deviceEventType" type="xsd:string" minOccurs="0" />

<xsd:element name="externalEventName" type="xsd:string" minOccurs="0" />

<xsd:element name="eventDateTime" type="xsd:dateTime" />

<xsd:element name="eventEndDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="deviceId" type="xsd:string" minOccurs="0" />

<xsd:element name="creationDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="statusUpdateDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="statusReason" type="xsd:string" minOccurs="0" />

<xsd:element name="rawEventInformation" type="xsd:anyType" minOccurs="0" maxOccurs="unbounded" />

<xsd:element name="externalSourceIdentifier" type="xsd:string" minOccurs="0" />

<xsd:element name="eventInformation" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="externalEventIdentifier" type="xsd:string" minOccurs="0" />

<xsd:element name="externalEventCategory" type="xsd:string" minOccurs="0" />

<xsd:element name="externalEventSeverity" type="xsd:string" minOccurs="0" />

<xsd:element name="externalDeviceType" type="xsd:string" minOccurs="0" />

<xsd:element name="externalServiceLocationId" type="xsd:string" minOccurs="0" />

<xsd:element name="externalCommunicationModuleIdentifier" type="xsd:string" minOccurs="0" />

<xsd:element name="externalGatewayIdentifier" type="xsd:string" minOccurs="0" />

<xsd:element name="externalStatusValue" type="xsd:string" minOccurs="0" />

<xsd:element name="externalStatusDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="externalCommandId" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="version" type="xsd:decimal" minOccurs="0" />

<xsd:element name="deviceIdentifierNumber" type="xsd:string" minOccurs="0" />

<xsd:element name="newDeviceEvent" type="xsd:string" minOccurs="0" />

<xsd:element name="processData" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="errorEncountered" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="dateTimesInStandard" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="logs" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="logsList" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="logsEntry" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="sequence" type="xsd:decimal" minOccurs="0" />

<xsd:element name="mo" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue1" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue2" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue3" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue4" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue5" type="xsd:string" minOccurs="0" />

<xsd:element name="logEntryType" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="toDos" />

<xsd:enumeration value="created" />

<xsd:enumeration value="statusTransitionError" />

<xsd:enumeration value="exception" />

<xsd:enumeration value="statusTransition" />

<xsd:enumeration value="system" />

<xsd:enumeration value="toDo" />

<xsd:enumeration value="userDetails" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="logDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="boStatus" type="xsd:string" minOccurs="0" />

<xsd:element name="description" type="xsd:string" minOccurs="0" />

<xsd:element name="user" type="xsd:string" minOccurs="0" />

<xsd:element name="logMessage" type="xsd:string" minOccurs="0" />

<xsd:element name="characteristicType" type="xsd:string" minOccurs="0" />

<xsd:element name="characteristicValue" type="xsd:string" minOccurs="0" />

<xsd:element name="adhocValue" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue1" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue2" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue3" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue4" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue5" type="xsd:string" minOccurs="0" />

<xsd:element name="messageCategory" type="xsd:decimal" minOccurs="0" />

<xsd:element name="messageNumber" type="xsd:decimal" minOccurs="0" />

<xsd:element name="messageParm1" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm2" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm3" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm4" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm5" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm6" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm7" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm8" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm9" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

<xsd:attribute name="dateTimeTagFormat" type="xsd:string" fixed="xsd" use="required" />

<xsd:attribute name="transactionType">

<xsd:simpleType>

<xsd:restriction base="xsd:token">

<xsd:enumeration value="RWOV" />

<xsd:enumeration value="FADD" />

<xsd:enumeration value="FUPD" />

<xsd:enumeration value="DEL" />

<xsd:enumeration value="UPD" />

<xsd:enumeration value="ADD" />

<xsd:enumeration value="READ" />

<xsd:enumeration value="REPL" />

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Device Event XML Format

This section describes the XML format used for inbound device events. This includes an example, descriptions of the individual XML elements, and the device event XML schema based on the D1-DeviceEventSeeder business object.

Example - Device Event

<D1-DeviceEventSeeder>

<externalSenderId>L+G</externalSenderId>

<deviceIdentifierNumber>GD_LL_SN100</deviceIdentifierNumber>

<externalEventName>GD_LL_TAMPER_INDICATION</externalEventName>

<rawEventInformation>D~Meter~GD_LL_SN100~GD_LL_ELECTRIC~1342395718~3~GD_HeadEnd_Power_Off~2010-09-09T13:11:41.0000000-05:00~Alert~Tamper indication on serial number GD_LL_SN100.~2010-09-09T13:11:41.0000000-05:00</rawEventInformation>

<eventDateTime>2010-09-09-13.11.41</eventDateTime>

<externalSourceIdentifier>EVENT_test.lg</externalSourceIdentifier>

<eventInformation>

<externalEventCategory>3</externalEventCategory>

<externalEventSeverity>Alert</externalEventSeverity>

<externalDeviceType>Meter</externalDeviceType>

<externalServiceLocationId>GD_LL_ELECTRIC</externalServiceLocationId>

<externalCommunicationModuleIdentifier>1342395718</externalCommunicationModuleIdentifier>

<externalStatusValue>Tamper indication on serial number GD_LL_SN100.</externalStatusValue>

<externalStatusDateTime>2010-09-09-13.11.41</externalStatusDateTime>

</eventInformation>

</D1-DeviceEventSeeder>

Element Descriptions - Device Events

The table below provides descriptions of the elements used in the device event XML format.

Element

Description

<{SERVICE_NAME}>

Root element containing a device event. This element should match the name of the inbound service used to import device events.

<externalSenderId>

Id of the external system. Used to identify the head-end system from which the event is being sent.

<deviceIdentifierNumber>

The identifier number of the device that experienced the event.

<externalEventName>

The name of the event as defined by the external system. This will be mapped to a standard name via a device mapping business object.

<rawEventInformation>

A string containing information about the event from the external system.

<eventDateTime>

The date and time of the event.

<externalSourceIdentifier>

The name of the file containing the device event.

<eventInformation>

Element containing specific information about the event

<externalEventCategory>

The event category as defined by the external system.

<externalEventSeverity>

The event severity as defined by the external system.

<externalDeviceType>

The device type as defined by the external system. Can be one of the following:

•

Meter

•

Collector

•

Router

<externalServiceLocationId>

The service location for the event defined by the external system.

<externalCommunicationModuleIdentifier>

The identifier for the communication module associated with the device.

<externalStatusValue>

Optional information related to the event.

<externalStatusDateTime>

Date and time at which optional information (specified in the <externalStatusValue> element was recorded.

Schema - Device Event Seeder (D1-DeviceEventSeeder) Business Object

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ouaf="http://ouaf.oracle.com/" targetNamespace="http://oracle.com/D1-DeviceEventSeeder.xsd" elementFormDefault="qualified">

<xsd:import namespace="http://ouaf.oracle.com/" />

<xsd:element name="D1-DeviceEventSeeder">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="deviceEventId" type="xsd:string" minOccurs="0" />

<xsd:element name="bo" type="xsd:string" minOccurs="0" />

<xsd:element name="boStatus" type="xsd:string" minOccurs="0" />

<xsd:element name="sender" type="xsd:string" minOccurs="0" />

<xsd:element name="externalSenderId" type="xsd:string" minOccurs="0" />

<xsd:element name="deviceEventType" type="xsd:string" minOccurs="0" />

<xsd:element name="externalEventName" type="xsd:string" minOccurs="0" />

<xsd:element name="eventDateTime" type="xsd:dateTime" />

<xsd:element name="eventEndDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="deviceId" type="xsd:string" minOccurs="0" />

<xsd:element name="creationDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="statusUpdateDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="statusReason" type="xsd:string" minOccurs="0" />

<xsd:element name="rawEventInformation" type="xsd:anyType" minOccurs="0" maxOccurs="unbounded" />

<xsd:element name="externalSourceIdentifier" type="xsd:string" minOccurs="0" />

<xsd:element name="eventInformation" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="externalEventIdentifier" type="xsd:string" minOccurs="0" />

<xsd:element name="externalEventCategory" type="xsd:string" minOccurs="0" />

<xsd:element name="externalEventSeverity" type="xsd:string" minOccurs="0" />

<xsd:element name="externalDeviceType" type="xsd:string" minOccurs="0" />

<xsd:element name="externalServiceLocationId" type="xsd:string" minOccurs="0" />

<xsd:element name="externalCommunicationModuleIdentifier" type="xsd:string" minOccurs="0" />

<xsd:element name="externalGatewayIdentifier" type="xsd:string" minOccurs="0" />

<xsd:element name="externalStatusValue" type="xsd:string" minOccurs="0" />

<xsd:element name="externalStatusDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="externalCommandId" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="version" type="xsd:decimal" minOccurs="0" />

<xsd:element name="deviceIdentifierNumber" type="xsd:string" minOccurs="0" />

<xsd:element name="newDeviceEvent" type="xsd:string" minOccurs="0" />

<xsd:element name="processData" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="errorEncountered" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="dateTimesInStandard" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="logs" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="logsList" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="logsEntry" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="sequence" type="xsd:decimal" minOccurs="0" />

<xsd:element name="mo" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue1" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue2" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue3" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue4" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue5" type="xsd:string" minOccurs="0" />

<xsd:element name="logEntryType" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="toDos" />

<xsd:enumeration value="created" />

<xsd:enumeration value="statusTransitionError" />

<xsd:enumeration value="exception" />

<xsd:enumeration value="statusTransition" />

<xsd:enumeration value="system" />

<xsd:enumeration value="toDo" />

<xsd:enumeration value="userDetails" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="logDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="boStatus" type="xsd:string" minOccurs="0" />

<xsd:element name="description" type="xsd:string" minOccurs="0" />

<xsd:element name="user" type="xsd:string" minOccurs="0" />

<xsd:element name="logMessage" type="xsd:string" minOccurs="0" />

<xsd:element name="characteristicType" type="xsd:string" minOccurs="0" />

<xsd:element name="characteristicValue" type="xsd:string" minOccurs="0" />

<xsd:element name="adhocValue" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue1" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue2" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue3" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue4" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue5" type="xsd:string" minOccurs="0" />

<xsd:element name="messageCategory" type="xsd:decimal" minOccurs="0" />

<xsd:element name="messageNumber" type="xsd:decimal" minOccurs="0" />

<xsd:element name="messageParm1" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm2" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm3" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm4" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm5" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm6" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm7" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm8" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm9" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

<xsd:attribute name="dateTimeTagFormat" type="xsd:string" fixed="xsd" use="required" />

<xsd:attribute name="transactionType">

<xsd:simpleType>

<xsd:restriction base="xsd:token">

<xsd:enumeration value="RWOV" />

<xsd:enumeration value="FADD" />

<xsd:enumeration value="FUPD" />

<xsd:enumeration value="DEL" />

<xsd:enumeration value="UPD" />

<xsd:enumeration value="ADD" />

<xsd:enumeration value="READ" />

<xsd:enumeration value="REPL" />

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Device Event XML Format

This section describes the XML format used for inbound device events. This includes an example, descriptions of the individual XML elements, and the device event XML schema based on the D1-DeviceEventSeeder business object.

Example - Device Event

<D1-DeviceEventSeeder>

<externalSenderId>L+G</externalSenderId>

<deviceIdentifierNumber>GD_LL_SN100</deviceIdentifierNumber>

<externalEventName>GD_LL_TAMPER_INDICATION</externalEventName>

<rawEventInformation>D~Meter~GD_LL_SN100~GD_LL_ELECTRIC~1342395718~3~GD_HeadEnd_Power_Off~2010-09-09T13:11:41.0000000-05:00~Alert~Tamper indication on serial number GD_LL_SN100.~2010-09-09T13:11:41.0000000-05:00</rawEventInformation>

<eventDateTime>2010-09-09-13.11.41</eventDateTime>

<externalSourceIdentifier>EVENT_test.lg</externalSourceIdentifier>

<eventInformation>

<externalEventCategory>3</externalEventCategory>

<externalEventSeverity>Alert</externalEventSeverity>

<externalDeviceType>Meter</externalDeviceType>

<externalServiceLocationId>GD_LL_ELECTRIC</externalServiceLocationId>

<externalCommunicationModuleIdentifier>1342395718</externalCommunicationModuleIdentifier>

<externalStatusValue>Tamper indication on serial number GD_LL_SN100.</externalStatusValue>

<externalStatusDateTime>2010-09-09-13.11.41</externalStatusDateTime>

</eventInformation>

</D1-DeviceEventSeeder>

Element Descriptions - Device Events

The table below provides descriptions of the elements used in the device event XML format.

Element

Description

<{SERVICE_NAME}>

Root element containing a device event. This element should match the name of the inbound service used to import device events.

<externalSenderId>

Id of the external system. Used to identify the head-end system from which the event is being sent.

<deviceIdentifierNumber>

The identifier number of the device that experienced the event.

<externalEventName>

The name of the event as defined by the external system. This will be mapped to a standard name via a device mapping business object.

<rawEventInformation>

A string containing information about the event from the external system.

<eventDateTime>

The date and time of the event.

<externalSourceIdentifier>

The name of the file containing the device event.

<eventInformation>

Element containing specific information about the event

<externalEventCategory>

The event category as defined by the external system.

<externalEventSeverity>

The event severity as defined by the external system.

<externalDeviceType>

The device type as defined by the external system. Can be one of the following:

•

Meter

•

Collector

•

Router

<externalServiceLocationId>

The service location for the event defined by the external system.

<externalCommunicationModuleIdentifier>

The identifier for the communication module associated with the device.

<externalStatusValue>

Optional information related to the event.

<externalStatusDateTime>

Date and time at which optional information (specified in the <externalStatusValue> element was recorded.

Schema - Device Event Seeder (D1-DeviceEventSeeder) Business Object

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ouaf="http://ouaf.oracle.com/" targetNamespace="http://oracle.com/D1-DeviceEventSeeder.xsd" elementFormDefault="qualified">

<xsd:import namespace="http://ouaf.oracle.com/" />

<xsd:element name="D1-DeviceEventSeeder">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="deviceEventId" type="xsd:string" minOccurs="0" />

<xsd:element name="bo" type="xsd:string" minOccurs="0" />

<xsd:element name="boStatus" type="xsd:string" minOccurs="0" />

<xsd:element name="sender" type="xsd:string" minOccurs="0" />

<xsd:element name="externalSenderId" type="xsd:string" minOccurs="0" />

<xsd:element name="deviceEventType" type="xsd:string" minOccurs="0" />

<xsd:element name="externalEventName" type="xsd:string" minOccurs="0" />

<xsd:element name="eventDateTime" type="xsd:dateTime" />

<xsd:element name="eventEndDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="deviceId" type="xsd:string" minOccurs="0" />

<xsd:element name="creationDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="statusUpdateDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="statusReason" type="xsd:string" minOccurs="0" />

<xsd:element name="rawEventInformation" type="xsd:anyType" minOccurs="0" maxOccurs="unbounded" />

<xsd:element name="externalSourceIdentifier" type="xsd:string" minOccurs="0" />

<xsd:element name="eventInformation" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="externalEventIdentifier" type="xsd:string" minOccurs="0" />

<xsd:element name="externalEventCategory" type="xsd:string" minOccurs="0" />

<xsd:element name="externalEventSeverity" type="xsd:string" minOccurs="0" />

<xsd:element name="externalDeviceType" type="xsd:string" minOccurs="0" />

<xsd:element name="externalServiceLocationId" type="xsd:string" minOccurs="0" />

<xsd:element name="externalCommunicationModuleIdentifier" type="xsd:string" minOccurs="0" />

<xsd:element name="externalGatewayIdentifier" type="xsd:string" minOccurs="0" />

<xsd:element name="externalStatusValue" type="xsd:string" minOccurs="0" />

<xsd:element name="externalStatusDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="externalCommandId" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="version" type="xsd:decimal" minOccurs="0" />

<xsd:element name="deviceIdentifierNumber" type="xsd:string" minOccurs="0" />

<xsd:element name="newDeviceEvent" type="xsd:string" minOccurs="0" />

<xsd:element name="processData" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="errorEncountered" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="dateTimesInStandard" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="no" />

<xsd:enumeration value="yes" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="logs" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="logsList" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="logsEntry" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="sequence" type="xsd:decimal" minOccurs="0" />

<xsd:element name="mo" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue1" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue2" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue3" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue4" type="xsd:string" minOccurs="0" />

<xsd:element name="pkValue5" type="xsd:string" minOccurs="0" />

<xsd:element name="logEntryType" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="toDos" />

<xsd:enumeration value="created" />

<xsd:enumeration value="statusTransitionError" />

<xsd:enumeration value="exception" />

<xsd:enumeration value="statusTransition" />

<xsd:enumeration value="system" />

<xsd:enumeration value="toDo" />

<xsd:enumeration value="userDetails" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="logDateTime" type="xsd:dateTime" minOccurs="0" />

<xsd:element name="boStatus" type="xsd:string" minOccurs="0" />

<xsd:element name="description" type="xsd:string" minOccurs="0" />

<xsd:element name="user" type="xsd:string" minOccurs="0" />

<xsd:element name="logMessage" type="xsd:string" minOccurs="0" />

<xsd:element name="characteristicType" type="xsd:string" minOccurs="0" />

<xsd:element name="characteristicValue" type="xsd:string" minOccurs="0" />

<xsd:element name="adhocValue" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue1" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue2" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue3" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue4" type="xsd:string" minOccurs="0" />

<xsd:element name="fkValue5" type="xsd:string" minOccurs="0" />

<xsd:element name="messageCategory" type="xsd:decimal" minOccurs="0" />

<xsd:element name="messageNumber" type="xsd:decimal" minOccurs="0" />

<xsd:element name="messageParm1" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm2" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm3" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm4" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm5" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm6" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm7" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm8" type="xsd:string" minOccurs="0" />

<xsd:element name="messageParm9" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

<xsd:attribute name="dateTimeTagFormat" type="xsd:string" fixed="xsd" use="required" />

<xsd:attribute name="transactionType">

<xsd:simpleType>

<xsd:restriction base="xsd:token">

<xsd:enumeration value="RWOV" />

<xsd:enumeration value="FADD" />

<xsd:enumeration value="FUPD" />

<xsd:enumeration value="DEL" />

<xsd:enumeration value="UPD" />

<xsd:enumeration value="ADD" />

<xsd:enumeration value="READ" />

<xsd:enumeration value="REPL" />

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Usage and Event Import - Message Driven Bean Configuration

This section describes the steps for configuring the Message Driven Bean (MDB) feature of Oracle Utilities Smart Grid Gateway to listen to inbound JMS messages. This feature is used when importing usage reading and device events form head-end systems. This section includes:

•

JMS Configuration

•

Message Driven Bean Configuration

•

Notification Queue Configuration

JMS Configuration

JMS configuration involves setting up JMS queues which will received inbound usage readings and device events. The JMS queues need to be created first on the application server where the OSB component is deployed. This server is referred to as remote server in the sections below. In the following section the JMS queue on the remote server is assumed to be created with the name DestinationQueueWatch-CM.

Note: The JMS changes described in the following sections are not persistent during patches or upgrades. They will need to be re-created after applying any patches or upgrades to Oracle Utilities Smart Grid Gateway. It is recommended to keep a backup of the $SPLEBASE/splapp/config.xml file.

Create a new JMS module

Log in to the Oracle Utilities Smart Grid Gateway Weblogic console and create a JMS Module with an appropriate name. Specify the following values for this JMS module:

•

Name : the name of JMS module. For example, JMSModule-CM

•

Target : the name of the target server where the Oracle Utilities Smart Grid Gateway application is running. This should be specified as myserver.

Create a Foreign JMS server

Create a Foreign JMS server under the JMS module created in the above step. Specify the following values for this foreign JMS server:

•

Name : Name of the foreign server. For example, JMSFAServer-CM

•

Target : This should be specified as myserver

•

JNDI Initial Context Factory : This should be specified as weblogic.jndi.WLInitialContextFactory

•

JNDI Connection URL : The URL of the server where OSB is deployed. For example: t3://osbserver:7001

•

JNDI Properties Credential : Password for the OSB server user.

•

JNDI Properties : The java.naming.security.principal additional property should be specified and set to the OSB server user. For example, java.naming.security.principal=weblogic

Create a Foreign Destination

Create a Foreign destination for each remote queue. Specify the following values for this foreign destination:

•

Name : Name of foreign destination. For instance, DestinationQueue-CM

•

Local JNDI Name : Local JNDI name for the foreign JMS queue. For example, ForeignDestinationQueue-CM

•

Remote JNDI Name : JNDI name of the queue on the remote server. For example, DestinationQueueWatch-CM

Create a Remote Connection Factory

Create a remote connection factory for the foreign JMS server. Specify the following values for this remote connection factory:

•

Name : Name of remote connection factory. For example, DestinationQueueConnectionFactory-CM

•

Local JNDI Name : Local JNDI name for the Remote Connection Factory. For example, ForegnDestinationQueueConnectionFactory-CM

•

Remote JNDI Name : JNDI name of the JMS Connection Factory on the remote server. For example, weblogic.jms.XAConnectionFactory

JMS Configuration

JMS configuration involves setting up JMS queues which will received inbound usage readings and device events. The JMS queues need to be created first on the application server where the OSB component is deployed. This server is referred to as remote server in the sections below. In the following section the JMS queue on the remote server is assumed to be created with the name DestinationQueueWatch-CM.

Note: The JMS changes described in the following sections are not persistent during patches or upgrades. They will need to be re-created after applying any patches or upgrades to Oracle Utilities Smart Grid Gateway. It is recommended to keep a backup of the $SPLEBASE/splapp/config.xml file.

Create a new JMS module

Log in to the Oracle Utilities Smart Grid Gateway Weblogic console and create a JMS Module with an appropriate name. Specify the following values for this JMS module:

•

Name : the name of JMS module. For example, JMSModule-CM

•

Target : the name of the target server where the Oracle Utilities Smart Grid Gateway application is running. This should be specified as myserver.

Create a Foreign JMS server

Create a Foreign JMS server under the JMS module created in the above step. Specify the following values for this foreign JMS server:

•

Name : Name of the foreign server. For example, JMSFAServer-CM

•

Target : This should be specified as myserver

•

JNDI Initial Context Factory : This should be specified as weblogic.jndi.WLInitialContextFactory

•

JNDI Connection URL : The URL of the server where OSB is deployed. For example: t3://osbserver:7001

•

JNDI Properties Credential : Password for the OSB server user.

•

JNDI Properties : The java.naming.security.principal additional property should be specified and set to the OSB server user. For example, java.naming.security.principal=weblogic

Create a Foreign Destination

Create a Foreign destination for each remote queue. Specify the following values for this foreign destination:

•

Name : Name of foreign destination. For instance, DestinationQueue-CM

•

Local JNDI Name : Local JNDI name for the foreign JMS queue. For example, ForeignDestinationQueue-CM

•

Remote JNDI Name : JNDI name of the queue on the remote server. For example, DestinationQueueWatch-CM

Create a Remote Connection Factory

Create a remote connection factory for the foreign JMS server. Specify the following values for this remote connection factory:

•

Name : Name of remote connection factory. For example, DestinationQueueConnectionFactory-CM

•

Local JNDI Name : Local JNDI name for the Remote Connection Factory. For example, ForegnDestinationQueueConnectionFactory-CM

•

Remote JNDI Name : JNDI name of the JMS Connection Factory on the remote server. For example, weblogic.jms.XAConnectionFactory

JMS Configuration

JMS configuration involves setting up JMS queues which will received inbound usage readings and device events. The JMS queues need to be created first on the application server where the OSB component is deployed. This server is referred to as remote server in the sections below. In the following section the JMS queue on the remote server is assumed to be created with the name DestinationQueueWatch-CM.

Note: The JMS changes described in the following sections are not persistent during patches or upgrades. They will need to be re-created after applying any patches or upgrades to Oracle Utilities Smart Grid Gateway. It is recommended to keep a backup of the $SPLEBASE/splapp/config.xml file.

Create a new JMS module

Log in to the Oracle Utilities Smart Grid Gateway Weblogic console and create a JMS Module with an appropriate name. Specify the following values for this JMS module:

•

Name : the name of JMS module. For example, JMSModule-CM

•

Target : the name of the target server where the Oracle Utilities Smart Grid Gateway application is running. This should be specified as myserver.

Create a Foreign JMS server

Create a Foreign JMS server under the JMS module created in the above step. Specify the following values for this foreign JMS server:

•

Name : Name of the foreign server. For example, JMSFAServer-CM

•

Target : This should be specified as myserver

•

JNDI Initial Context Factory : This should be specified as weblogic.jndi.WLInitialContextFactory

•

JNDI Connection URL : The URL of the server where OSB is deployed. For example: t3://osbserver:7001

•

JNDI Properties Credential : Password for the OSB server user.

•

JNDI Properties : The java.naming.security.principal additional property should be specified and set to the OSB server user. For example, java.naming.security.principal=weblogic

Create a Foreign Destination

Create a Foreign destination for each remote queue. Specify the following values for this foreign destination:

•

Name : Name of foreign destination. For instance, DestinationQueue-CM

•

Local JNDI Name : Local JNDI name for the foreign JMS queue. For example, ForeignDestinationQueue-CM

•

Remote JNDI Name : JNDI name of the queue on the remote server. For example, DestinationQueueWatch-CM

Create a Remote Connection Factory

Create a remote connection factory for the foreign JMS server. Specify the following values for this remote connection factory:

•

Name : Name of remote connection factory. For example, DestinationQueueConnectionFactory-CM

•

Local JNDI Name : Local JNDI name for the Remote Connection Factory. For example, ForegnDestinationQueueConnectionFactory-CM

•

Remote JNDI Name : JNDI name of the JMS Connection Factory on the remote server. For example, weblogic.jms.XAConnectionFactory

JMS Configuration

JMS configuration involves setting up JMS queues which will received inbound usage readings and device events. The JMS queues need to be created first on the application server where the OSB component is deployed. This server is referred to as remote server in the sections below. In the following section the JMS queue on the remote server is assumed to be created with the name DestinationQueueWatch-CM.

Note: The JMS changes described in the following sections are not persistent during patches or upgrades. They will need to be re-created after applying any patches or upgrades to Oracle Utilities Smart Grid Gateway. It is recommended to keep a backup of the $SPLEBASE/splapp/config.xml file.

Create a new JMS module

Log in to the Oracle Utilities Smart Grid Gateway Weblogic console and create a JMS Module with an appropriate name. Specify the following values for this JMS module:

•

Name : the name of JMS module. For example, JMSModule-CM

•

Target : the name of the target server where the Oracle Utilities Smart Grid Gateway application is running. This should be specified as myserver.

Create a Foreign JMS server

Create a Foreign JMS server under the JMS module created in the above step. Specify the following values for this foreign JMS server:

•

Name : Name of the foreign server. For example, JMSFAServer-CM

•

Target : This should be specified as myserver

•

JNDI Initial Context Factory : This should be specified as weblogic.jndi.WLInitialContextFactory

•

JNDI Connection URL : The URL of the server where OSB is deployed. For example: t3://osbserver:7001

•

JNDI Properties Credential : Password for the OSB server user.

•

JNDI Properties : The java.naming.security.principal additional property should be specified and set to the OSB server user. For example, java.naming.security.principal=weblogic

Create a Foreign Destination

Create a Foreign destination for each remote queue. Specify the following values for this foreign destination:

•

Name : Name of foreign destination. For instance, DestinationQueue-CM

•

Local JNDI Name : Local JNDI name for the foreign JMS queue. For example, ForeignDestinationQueue-CM

•

Remote JNDI Name : JNDI name of the queue on the remote server. For example, DestinationQueueWatch-CM

Create a Remote Connection Factory

Create a remote connection factory for the foreign JMS server. Specify the following values for this remote connection factory:

•

Name : Name of remote connection factory. For example, DestinationQueueConnectionFactory-CM

•

Local JNDI Name : Local JNDI name for the Remote Connection Factory. For example, ForegnDestinationQueueConnectionFactory-CM

•

Remote JNDI Name : JNDI name of the JMS Connection Factory on the remote server. For example, weblogic.jms.XAConnectionFactory

JMS Configuration

JMS configuration involves setting up JMS queues which will received inbound usage readings and device events. The JMS queues need to be created first on the application server where the OSB component is deployed. This server is referred to as remote server in the sections below. In the following section the JMS queue on the remote server is assumed to be created with the name DestinationQueueWatch-CM.

Note: The JMS changes described in the following sections are not persistent during patches or upgrades. They will need to be re-created after applying any patches or upgrades to Oracle Utilities Smart Grid Gateway. It is recommended to keep a backup of the $SPLEBASE/splapp/config.xml file.

Create a new JMS module

Log in to the Oracle Utilities Smart Grid Gateway Weblogic console and create a JMS Module with an appropriate name. Specify the following values for this JMS module:

•

Name : the name of JMS module. For example, JMSModule-CM

•

Target : the name of the target server where the Oracle Utilities Smart Grid Gateway application is running. This should be specified as myserver.

Create a Foreign JMS server

Create a Foreign JMS server under the JMS module created in the above step. Specify the following values for this foreign JMS server:

•

Name : Name of the foreign server. For example, JMSFAServer-CM

•

Target : This should be specified as myserver

•

JNDI Initial Context Factory : This should be specified as weblogic.jndi.WLInitialContextFactory

•

JNDI Connection URL : The URL of the server where OSB is deployed. For example: t3://osbserver:7001

•

JNDI Properties Credential : Password for the OSB server user.

•

JNDI Properties : The java.naming.security.principal additional property should be specified and set to the OSB server user. For example, java.naming.security.principal=weblogic

Create a Foreign Destination

Create a Foreign destination for each remote queue. Specify the following values for this foreign destination:

•

Name : Name of foreign destination. For instance, DestinationQueue-CM

•

Local JNDI Name : Local JNDI name for the foreign JMS queue. For example, ForeignDestinationQueue-CM

•

Remote JNDI Name : JNDI name of the queue on the remote server. For example, DestinationQueueWatch-CM

Create a Remote Connection Factory

Create a remote connection factory for the foreign JMS server. Specify the following values for this remote connection factory:

•

Name : Name of remote connection factory. For example, DestinationQueueConnectionFactory-CM

•

Local JNDI Name : Local JNDI name for the Remote Connection Factory. For example, ForegnDestinationQueueConnectionFactory-CM

•

Remote JNDI Name : JNDI name of the JMS Connection Factory on the remote server. For example, weblogic.jms.XAConnectionFactory

Message Driven Bean Configuration

Configuration of message driven beans (MDB) involved modifying the ejb-jar.xml and ejb-weblogic-jar.xml configuration files delivered with Oracle Utilities Smart Grid Gateway. It is recommended that instead of modifying these files directly you create "Customer Modification" (CM) versions of these files to make changes to these configuration files. This ensures that your modifications are not overwritten by future application patches.

The following section describes the changes required in the CM files for configuring the MDBs to read from the foreign JMS queues set up in the steps above (see JMS Configuration ). This requires creating the following files under $SPLEBASE/templates -

•

cm_ejb-jar.xml.wls.jms_1.include

•

cm_ejb-jar.xml.wls.jms_2.include

•

cm_weblogic-ejb-jar.xml.jms.include.

Note : After making these changes the initialSetup script needs to be run and Oracle Utilities Smart Grid Gateway application needs to be redeployed. However the initialSetup script will overwrite the JMS configuration changes made in the steps above. So it is recommended to keep a backup of the $SPLEBASE/splapp/config.xml file before running this script.

Changes to cm_ejb-jar.xml.wls.jms_1.include

Below is an an example of the cm_ejb-jar.xml.wls.jms_1.include file:

<message-driven>

<description>MDB for DestinationQueue-CM</description>

<display-name>DestinationQueueWatcher-CM</display-name>

<ejb-name>DestinationQueueWatch-CM</ejb-name>

<ejb-class>com.splwg.ejb.mdb.MessageProcessor</ejb-class>

<messaging-type>javax.jms.MessageListener</messaging-type>

<transaction-type>Bean</transaction-type>

<message-destination-type>javax.jms.Queue</message-destination-type>

</message-driven>

The values specified in the above file include the following:

•

ejb-name : This is the name of the MDB.

Changes to cm_ejb-jar.xml.wls.jms_2.include

Below is an example of the cm_ejb-jar.xml.wls.jms_2.include file:

<assembly-descriptor>

<security-role>

<role-name>cisusers</role-name>

</security-role>

<container-transaction>

<method>

<ejb-name>DestinationQueueWatch-CM</ejb-name>

<method-name>onMessage</method-name>

</method>

<trans-attribute>NotSupported</trans-attribute>

</container-transaction>

</assembly-descriptor>

The values specified in the above file include the following:

•

ejb-name : This is the name of the MDB.

Changes to cm_weblogic-ejb-jar.xml.jms.include

Below is an example of the cm_weblogic-ejb-jar.xml.jms.include file:

<weblogic-enterprise-bean>

<ejb-name>DestinationQueueWatch-CM</ejb-name>

<message-driven-descriptor>

<pool>

<max-beans-in-free-pool>5</max-beans-in-free-pool>

<initial-beans-in-free-pool>1</initial-beans-in-free-pool>

</pool>

<destination-jndi-name>ForeignDestinationQueue-CM</destination-jndi-name>

<connection-factory-jndi-name>ForeignConnectionFactory-CM</connection-factory-jndi-name>

</message-driven-descriptor>

</weblogic-enterprise-bean>

The values specified in the above file include the following:

•

ejb-name : This should be the name of the MDB as specified in ejb-jar.xml.

•

destination-jndi-name : This should be the JNDI name of the foreign destination as provided in JMS module ' Foreign server ' Foreign destination ' Local JNDI name.

•

connection-factory-jndi-name : This should be the JNDI name of the connection factory as provided in JMS module ' Foreign server ' Remote Connection Factory ' Local JNDI name.

Message Driven Bean Configuration

Configuration of message driven beans (MDB) involved modifying the ejb-jar.xml and ejb-weblogic-jar.xml configuration files delivered with Oracle Utilities Smart Grid Gateway. It is recommended that instead of modifying these files directly you create "Customer Modification" (CM) versions of these files to make changes to these configuration files. This ensures that your modifications are not overwritten by future application patches.

The following section describes the changes required in the CM files for configuring the MDBs to read from the foreign JMS queues set up in the steps above (see JMS Configuration ). This requires creating the following files under $SPLEBASE/templates -

•

cm_ejb-jar.xml.wls.jms_1.include

•

cm_ejb-jar.xml.wls.jms_2.include

•

cm_weblogic-ejb-jar.xml.jms.include.

Note : After making these changes the initialSetup script needs to be run and Oracle Utilities Smart Grid Gateway application needs to be redeployed. However the initialSetup script will overwrite the JMS configuration changes made in the steps above. So it is recommended to keep a backup of the $SPLEBASE/splapp/config.xml file before running this script.

Changes to cm_ejb-jar.xml.wls.jms_1.include

Below is an an example of the cm_ejb-jar.xml.wls.jms_1.include file:

<message-driven>

<description>MDB for DestinationQueue-CM</description>

<display-name>DestinationQueueWatcher-CM</display-name>

<ejb-name>DestinationQueueWatch-CM</ejb-name>

<ejb-class>com.splwg.ejb.mdb.MessageProcessor</ejb-class>

<messaging-type>javax.jms.MessageListener</messaging-type>

<transaction-type>Bean</transaction-type>

<message-destination-type>javax.jms.Queue</message-destination-type>

</message-driven>

The values specified in the above file include the following:

•

ejb-name : This is the name of the MDB.

Changes to cm_ejb-jar.xml.wls.jms_2.include

Below is an example of the cm_ejb-jar.xml.wls.jms_2.include file:

<assembly-descriptor>

<security-role>

<role-name>cisusers</role-name>

</security-role>

<container-transaction>

<method>

<ejb-name>DestinationQueueWatch-CM</ejb-name>

<method-name>onMessage</method-name>

</method>

<trans-attribute>NotSupported</trans-attribute>

</container-transaction>

</assembly-descriptor>

The values specified in the above file include the following:

•

ejb-name : This is the name of the MDB.

Changes to cm_weblogic-ejb-jar.xml.jms.include

Below is an example of the cm_weblogic-ejb-jar.xml.jms.include file:

<weblogic-enterprise-bean>

<ejb-name>DestinationQueueWatch-CM</ejb-name>

<message-driven-descriptor>

<pool>

<max-beans-in-free-pool>5</max-beans-in-free-pool>

<initial-beans-in-free-pool>1</initial-beans-in-free-pool>

</pool>

<destination-jndi-name>ForeignDestinationQueue-CM</destination-jndi-name>

<connection-factory-jndi-name>ForeignConnectionFactory-CM</connection-factory-jndi-name>

</message-driven-descriptor>

</weblogic-enterprise-bean>

The values specified in the above file include the following:

•

ejb-name : This should be the name of the MDB as specified in ejb-jar.xml.

•

destination-jndi-name : This should be the JNDI name of the foreign destination as provided in JMS module ' Foreign server ' Foreign destination ' Local JNDI name.

•

connection-factory-jndi-name : This should be the JNDI name of the connection factory as provided in JMS module ' Foreign server ' Remote Connection Factory ' Local JNDI name.

Message Driven Bean Configuration

Configuration of message driven beans (MDB) involved modifying the ejb-jar.xml and ejb-weblogic-jar.xml configuration files delivered with Oracle Utilities Smart Grid Gateway. It is recommended that instead of modifying these files directly you create "Customer Modification" (CM) versions of these files to make changes to these configuration files. This ensures that your modifications are not overwritten by future application patches.

The following section describes the changes required in the CM files for configuring the MDBs to read from the foreign JMS queues set up in the steps above (see JMS Configuration ). This requires creating the following files under $SPLEBASE/templates -

•

cm_ejb-jar.xml.wls.jms_1.include

•

cm_ejb-jar.xml.wls.jms_2.include

•

cm_weblogic-ejb-jar.xml.jms.include.

Note : After making these changes the initialSetup script needs to be run and Oracle Utilities Smart Grid Gateway application needs to be redeployed. However the initialSetup script will overwrite the JMS configuration changes made in the steps above. So it is recommended to keep a backup of the $SPLEBASE/splapp/config.xml file before running this script.

Changes to cm_ejb-jar.xml.wls.jms_1.include

Below is an an example of the cm_ejb-jar.xml.wls.jms_1.include file:

<message-driven>

<description>MDB for DestinationQueue-CM</description>

<display-name>DestinationQueueWatcher-CM</display-name>

<ejb-name>DestinationQueueWatch-CM</ejb-name>

<ejb-class>com.splwg.ejb.mdb.MessageProcessor</ejb-class>

<messaging-type>javax.jms.MessageListener</messaging-type>

<transaction-type>Bean</transaction-type>

<message-destination-type>javax.jms.Queue</message-destination-type>

</message-driven>

The values specified in the above file include the following:

•

ejb-name : This is the name of the MDB.

Changes to cm_ejb-jar.xml.wls.jms_2.include

Below is an example of the cm_ejb-jar.xml.wls.jms_2.include file:

<assembly-descriptor>

<security-role>

<role-name>cisusers</role-name>

</security-role>

<container-transaction>

<method>

<ejb-name>DestinationQueueWatch-CM</ejb-name>

<method-name>onMessage</method-name>

</method>

<trans-attribute>NotSupported</trans-attribute>

</container-transaction>

</assembly-descriptor>

The values specified in the above file include the following:

•

ejb-name : This is the name of the MDB.

Changes to cm_weblogic-ejb-jar.xml.jms.include

Below is an example of the cm_weblogic-ejb-jar.xml.jms.include file:

<weblogic-enterprise-bean>

<ejb-name>DestinationQueueWatch-CM</ejb-name>

<message-driven-descriptor>

<pool>

<max-beans-in-free-pool>5</max-beans-in-free-pool>

<initial-beans-in-free-pool>1</initial-beans-in-free-pool>

</pool>

<destination-jndi-name>ForeignDestinationQueue-CM</destination-jndi-name>

<connection-factory-jndi-name>ForeignConnectionFactory-CM</connection-factory-jndi-name>

</message-driven-descriptor>

</weblogic-enterprise-bean>

The values specified in the above file include the following:

•

ejb-name : This should be the name of the MDB as specified in ejb-jar.xml.

•

destination-jndi-name : This should be the JNDI name of the foreign destination as provided in JMS module ' Foreign server ' Foreign destination ' Local JNDI name.

•

connection-factory-jndi-name : This should be the JNDI name of the connection factory as provided in JMS module ' Foreign server ' Remote Connection Factory ' Local JNDI name.

Message Driven Bean Configuration

Configuration of message driven beans (MDB) involved modifying the ejb-jar.xml and ejb-weblogic-jar.xml configuration files delivered with Oracle Utilities Smart Grid Gateway. It is recommended that instead of modifying these files directly you create "Customer Modification" (CM) versions of these files to make changes to these configuration files. This ensures that your modifications are not overwritten by future application patches.

The following section describes the changes required in the CM files for configuring the MDBs to read from the foreign JMS queues set up in the steps above (see JMS Configuration ). This requires creating the following files under $SPLEBASE/templates -

•

cm_ejb-jar.xml.wls.jms_1.include

•

cm_ejb-jar.xml.wls.jms_2.include

•

cm_weblogic-ejb-jar.xml.jms.include.

Note : After making these changes the initialSetup script needs to be run and Oracle Utilities Smart Grid Gateway application needs to be redeployed. However the initialSetup script will overwrite the JMS configuration changes made in the steps above. So it is recommended to keep a backup of the $SPLEBASE/splapp/config.xml file before running this script.

Changes to cm_ejb-jar.xml.wls.jms_1.include

Below is an an example of the cm_ejb-jar.xml.wls.jms_1.include file:

<message-driven>

<description>MDB for DestinationQueue-CM</description>

<display-name>DestinationQueueWatcher-CM</display-name>

<ejb-name>DestinationQueueWatch-CM</ejb-name>

<ejb-class>com.splwg.ejb.mdb.MessageProcessor</ejb-class>

<messaging-type>javax.jms.MessageListener</messaging-type>

<transaction-type>Bean</transaction-type>

<message-destination-type>javax.jms.Queue</message-destination-type>

</message-driven>

The values specified in the above file include the following:

•

ejb-name : This is the name of the MDB.

Changes to cm_ejb-jar.xml.wls.jms_2.include

Below is an example of the cm_ejb-jar.xml.wls.jms_2.include file:

<assembly-descriptor>

<security-role>

<role-name>cisusers</role-name>

</security-role>

<container-transaction>

<method>

<ejb-name>DestinationQueueWatch-CM</ejb-name>

<method-name>onMessage</method-name>

</method>

<trans-attribute>NotSupported</trans-attribute>

</container-transaction>

</assembly-descriptor>

The values specified in the above file include the following:

•

ejb-name : This is the name of the MDB.

Changes to cm_weblogic-ejb-jar.xml.jms.include

Below is an example of the cm_weblogic-ejb-jar.xml.jms.include file:

<weblogic-enterprise-bean>

<ejb-name>DestinationQueueWatch-CM</ejb-name>

<message-driven-descriptor>

<pool>

<max-beans-in-free-pool>5</max-beans-in-free-pool>

<initial-beans-in-free-pool>1</initial-beans-in-free-pool>

</pool>

<destination-jndi-name>ForeignDestinationQueue-CM</destination-jndi-name>

<connection-factory-jndi-name>ForeignConnectionFactory-CM</connection-factory-jndi-name>

</message-driven-descriptor>

</weblogic-enterprise-bean>

The values specified in the above file include the following:

•

ejb-name : This should be the name of the MDB as specified in ejb-jar.xml.

•

destination-jndi-name : This should be the JNDI name of the foreign destination as provided in JMS module ' Foreign server ' Foreign destination ' Local JNDI name.

•

connection-factory-jndi-name : This should be the JNDI name of the connection factory as provided in JMS module ' Foreign server ' Remote Connection Factory ' Local JNDI name.

Notification Queue Configuration

Payload statistics and payload summary records must be submitted sequentially in order for them to be processed correctly. To prevent them from being processed at the same time, you should set the number of notification queue polling threads to 1. Follow these steps to configure the number of notification queue threads:

1.

Log in to the WebLogic Server Administration Console.

2.

Under Helpful Tools, click Configure Applications.

3.

Click on SPLService.

4.

Click on the NotificationQueue link. for the EJB that you want to configure.

5.

Go to the Configuration tab.

6.

In the Change Center, click Lock & Edit.

7.

Specify the new value of polling threads in Max Beans in Free Pool.

8.

Click Save.

9.

Click Release Configuration.

10.

Restart the OUAF WebLogic instance.

Sample Implementation

This chapter describes the steps involved in configuring Oracle Utilities Smart Grid Gateway in a simple example implementation, including the following:

•

Implementation Description and Requirements

•

Implementation Steps

Note : The implementation described in this chapter is intended for example purposes only, and is intentionally simple, and as such does not involve configuration of every type of object described in this book. Also, this example assumes that the base package admin business objects (device type, measuring component type, etc.) meet the requirements of the implementation.

Note : References to objects and options pre-fixed with "D2" are available only with Oracle Utilities Meter Data Management, and included for illustrative purposes only.

Implementation Description and Requirements

The sample implementation described in this chapter will be for a small electric utility providing service to a small town that includes residential, commercial, and industrial customers. The details and requirements of this implementation are summarized as follows

Requirement

Description

Types of Customers

•

Residential (approximately 50,000)

•

Commercial (approximately 1,000)

•

Industrial (approximately 100)

Types of Meters

•

Residential: Scalar, single register

•

Commercial: Interval channel/scalar register

•

Industrial: Two interval channels

Meter Manufacturers / Head-End Systems

•

MetersRUs: Scalar (used for residential customers)

•

MeterTech, Inc.: Interval (used for commercial and industrial customer)

Usage Metered

•

Residential: KWH (scalar)

•

Commercial: KWH (interval and scalar)

•

Industrial: KWH and KVARH (interval)

Readings/Measurement Data

•

Scalar (for residential and commercial)

•

Interval (for commercial and industrial, 15 minutes)

Both head-end systems use their own UOM codes.

Device Events

Both head-end systems listed above send standard and "paired" device events, and use their own device event names.

Meter Commands

Both head-end systems support the following commands:

•

Commission Device

•

Decommission Device

•

Device Status Check

•

On-Demand Read (interval and scalar)

•

Remote Connect

•

Remote Disconnect

Each command sends and received a single message when invoking the command.

Validation, Editing, and Estimation Rules

Validation, editing, and estimation is performed by Oracle Utilities Meter Data Management.*

Bill Determinants

Bill determinant calculations are performed by Oracle Utilities Meter Data Management.*

Billing System

Oracle Utilities Customer Care and Billing

*See Chapter 16: Sample Implementation in the Oracle Utilities Meter Data Management Configuration Guide for examples of implementing VEE and bill determinant calculations.

Implementation Steps

This section outlines the steps in configuring Oracle Utilities Smart Grid Gateway to meet the requirements outlined above. These steps include:

1.

Design and Create Business Objects

In this first step, we’ll outline the specific business objects and other configuration data required to address the sample requirements.

2.

Create Admin Data

In this step, we’ll outline the admin data that would need to be created to address the sample requirements.

3.

Create Master Data

In this step, we’ll outline the master data (individual devices, service points, etc.) that would need to be created to address the sample requirements.

Design and Create Business Objects

The first step in implementing and configuring the system is to identify the business objects (and related configuration objects) needed to meet the requirements of the implementation. This section outlines the business objects and other significant configuration objects that could be created to meet the requirements of our sample implementation. This does NOT include listings of all configuration objects needed (such as individual display and maintenance UI maps, portal navigation options, etc.).

Service Points and Device Installation

For service point and device installation data, we would need to create the following:

Service Points : Service point business objects for each type of customer, as follows:

•

Residential: CM-ResidentialSP

•

Commercial: CM-CommercialSP

•

Industrial: CM-IndustrialSP

Contacts : Contact business objects for each type of customer, as follows:

•

Residential: CM-ResPerson

•

Commercial: CM-ComBusiness

•

Industrial: CM-IndBusiness

Install Events : Install event business objects for each type of customer, as follows:

•

Residential: CM-ResidentialMeterInstallEvent

•

Commercial: CM-CommercialMeterInstallEvent

•

Industrial: CM-IndustrialMeterInstallEvent

Service Providers : Service provider business objects for each head-end system, and for the billing system, as follows:

•

Head-End System: CM-HeadEndMRU (Meters R Us)

•

Head-End System: CM-HeadEndMT (Meter Tech, Inc.)

•

Billing System: CM-ExternalAppCCB

Devices and Measuring Components

For devices and measuring components, we would need to create the following:

Devices : Device business objects for each type of meter, as follows:

•

Residential: CM-ScalarRegister

•

Install Event BO: CM-ResidentialInstallEvent (see above)

•

Valid Command Request BO: D1-DeviceCommission, etc.* (see below)

•

Commercial: CM-IntChanScalarReg

•

Install Event BO: CM-CommercialInstallEvent (see above)

•

Valid Command Request BO: D1-DeviceCommission, etc.* (see below)

•

Industrial: CM-Interval2Channels

•

Install Event BO: CM-IndustrialInstallEvent (see above)

•

Valid Command Request BO: D1-DeviceCommission, etc.* (see below)

*Note : Each device business object should specify the specific commands available for devices based on that business object

Measuring Components : Measuring component business objects for scalar registers and/or interval channels, as follows:

•

Residential - Scalar Register: CM-ResScalarRegister

•

Commercial/Industrial - Interval Channel: CM-IntervalChannel (used for both commercial and industrial meters)

•

Commercial - Scalar Register: CM-ScalarValRegister

Measurement Data

For measurement data, we would need to create the following:

Initial Measurement Data : Initial load, estimation, and manual initial measurement business objects for each reading/measurement type, as follows:

•

Initial Load - Interval: CM-InitialLoadIMDInterval

•

Initial Load - Scalar: CM-InitialLoadIMDScalar

•

Estimation - Interval: CM-EstimationIMDInterval

•

Estimation - Scalar: CM-EstimationIMDScalar

•

Manual - Interval: CM-ManualIMDInterval

•

Manual - Scalar: CM-ManualIMDScalar

Measurements : A single measurement business object for all final measurements, as follows:

•

Final Measurement: CM-FinalMeasurement

UOM Mapping : UOM mapping extendable lookup business objects for each head-end system, as follows:

•

MetersRUs: CM-MRUUOMMapping

•

MeterTech, Inc.: CM-MTUOMMapping

Device Events

For device events, we would need to create the following:

Device Events : Device event business objects for "standard" and "paired" device events, as follows:

•

Standard Device Event: CM-StandardDeviceEvent

•

Paired Device Event - First: CM-PairedDeviceEventFirst

•

Paired Device Event - Last: CM-PairedDeviceEventLast

Device Event Mapping : Device event mapping extendable lookup business objects for each head-end system, as follows:

•

MetersRUs: CM-MRUDeviceEventMapping

•

MeterTech, Inc.: CM-MTDeviceEventMapping

Meter Commands

For meter commands data, we would need to create the following:

Activities : For activities, this implementation can use the base package business objects, including the activity command business objects.

Outbound Communication : Outbound communication business objects for each command, as follows:

•

Commission Device: CM-InitiateCommissionDevice

•

Decommission Device: CM-InitiateDecommissionDevice

•

Device Status Check: CM-InitiateDeviceStatusCheck

•

On-Demand Read Interval: CM-InitiateOnDemandReadInterval

•

On-Demand Read Scalar: CM-InitiateOnDemandReadScalar

•

Remote Connect: CM-InitiateRemoteConnect

•

Remote Disconnect: CM-InitiateRemoteDisconnect

Inbound Communication : Inbound communication business objects for each command response, as follows:

•

Commission Device: CM-CommissionDeviceResponse

•

Decommission Device: CM-DecommissionDeviceResponse

•

Device Status Check: Cm-DeviceStatusCheckResponse

•

On-Demand Read Interval: CM-OnDemandReadIntervalResponse

•

On-Demand Read Scalar: CM-OnDemandReadScalarResponse

•

Remote Connect: CM-RemoteConnectResponse

•

Remote Disconnect: CM-RemoteDisconnectResponse

Completion Events : This implementation can use the base package completion event business objects.

Note: Because this implementation supports two head-end systems, you would need business objects for each communication for each head-end system. This list is for only one head-end system.

Design and Create Business Objects

The first step in implementing and configuring the system is to identify the business objects (and related configuration objects) needed to meet the requirements of the implementation. This section outlines the business objects and other significant configuration objects that could be created to meet the requirements of our sample implementation. This does NOT include listings of all configuration objects needed (such as individual display and maintenance UI maps, portal navigation options, etc.).

Service Points and Device Installation

For service point and device installation data, we would need to create the following:

Service Points : Service point business objects for each type of customer, as follows:

•

Residential: CM-ResidentialSP

•

Commercial: CM-CommercialSP

•

Industrial: CM-IndustrialSP

Contacts : Contact business objects for each type of customer, as follows:

•

Residential: CM-ResPerson

•

Commercial: CM-ComBusiness

•

Industrial: CM-IndBusiness

Install Events : Install event business objects for each type of customer, as follows:

•

Residential: CM-ResidentialMeterInstallEvent

•

Commercial: CM-CommercialMeterInstallEvent

•

Industrial: CM-IndustrialMeterInstallEvent

Service Providers : Service provider business objects for each head-end system, and for the billing system, as follows:

•

Head-End System: CM-HeadEndMRU (Meters R Us)

•

Head-End System: CM-HeadEndMT (Meter Tech, Inc.)

•

Billing System: CM-ExternalAppCCB

Devices and Measuring Components

For devices and measuring components, we would need to create the following:

Devices : Device business objects for each type of meter, as follows:

•

Residential: CM-ScalarRegister

•

Install Event BO: CM-ResidentialInstallEvent (see above)

•

Valid Command Request BO: D1-DeviceCommission, etc.* (see below)

•

Commercial: CM-IntChanScalarReg

•

Install Event BO: CM-CommercialInstallEvent (see above)

•

Valid Command Request BO: D1-DeviceCommission, etc.* (see below)

•

Industrial: CM-Interval2Channels

•

Install Event BO: CM-IndustrialInstallEvent (see above)

•

Valid Command Request BO: D1-DeviceCommission, etc.* (see below)

*Note : Each device business object should specify the specific commands available for devices based on that business object

Measuring Components : Measuring component business objects for scalar registers and/or interval channels, as follows:

•

Residential - Scalar Register: CM-ResScalarRegister

•

Commercial/Industrial - Interval Channel: CM-IntervalChannel (used for both commercial and industrial meters)

•

Commercial - Scalar Register: CM-ScalarValRegister

Measurement Data

For measurement data, we would need to create the following:

Initial Measurement Data : Initial load, estimation, and manual initial measurement business objects for each reading/measurement type, as follows:

•

Initial Load - Interval: CM-InitialLoadIMDInterval

•

Initial Load - Scalar: CM-InitialLoadIMDScalar

•

Estimation - Interval: CM-EstimationIMDInterval

•

Estimation - Scalar: CM-EstimationIMDScalar

•

Manual - Interval: CM-ManualIMDInterval

•

Manual - Scalar: CM-ManualIMDScalar

Measurements : A single measurement business object for all final measurements, as follows:

•

Final Measurement: CM-FinalMeasurement

UOM Mapping : UOM mapping extendable lookup business objects for each head-end system, as follows:

•

MetersRUs: CM-MRUUOMMapping

•

MeterTech, Inc.: CM-MTUOMMapping

Device Events

For device events, we would need to create the following:

Device Events : Device event business objects for "standard" and "paired" device events, as follows:

•

Standard Device Event: CM-StandardDeviceEvent

•

Paired Device Event - First: CM-PairedDeviceEventFirst

•

Paired Device Event - Last: CM-PairedDeviceEventLast

Device Event Mapping : Device event mapping extendable lookup business objects for each head-end system, as follows:

•

MetersRUs: CM-MRUDeviceEventMapping

•

MeterTech, Inc.: CM-MTDeviceEventMapping

Meter Commands

For meter commands data, we would need to create the following:

Activities : For activities, this implementation can use the base package business objects, including the activity command business objects.

Outbound Communication : Outbound communication business objects for each command, as follows:

•

Commission Device: CM-InitiateCommissionDevice

•

Decommission Device: CM-InitiateDecommissionDevice

•

Device Status Check: CM-InitiateDeviceStatusCheck

•

On-Demand Read Interval: CM-InitiateOnDemandReadInterval

•

On-Demand Read Scalar: CM-InitiateOnDemandReadScalar

•

Remote Connect: CM-InitiateRemoteConnect

•

Remote Disconnect: CM-InitiateRemoteDisconnect

Inbound Communication : Inbound communication business objects for each command response, as follows:

•

Commission Device: CM-CommissionDeviceResponse

•

Decommission Device: CM-DecommissionDeviceResponse

•

Device Status Check: Cm-DeviceStatusCheckResponse

•

On-Demand Read Interval: CM-OnDemandReadIntervalResponse

•

On-Demand Read Scalar: CM-OnDemandReadScalarResponse

•

Remote Connect: CM-RemoteConnectResponse

•

Remote Disconnect: CM-RemoteDisconnectResponse

Completion Events : This implementation can use the base package completion event business objects.

Note: Because this implementation supports two head-end systems, you would need business objects for each communication for each head-end system. This list is for only one head-end system.

Design and Create Business Objects

The first step in implementing and configuring the system is to identify the business objects (and related configuration objects) needed to meet the requirements of the implementation. This section outlines the business objects and other significant configuration objects that could be created to meet the requirements of our sample implementation. This does NOT include listings of all configuration objects needed (such as individual display and maintenance UI maps, portal navigation options, etc.).

Service Points and Device Installation

For service point and device installation data, we would need to create the following:

Service Points : Service point business objects for each type of customer, as follows:

•

Residential: CM-ResidentialSP

•

Commercial: CM-CommercialSP

•

Industrial: CM-IndustrialSP

Contacts : Contact business objects for each type of customer, as follows:

•

Residential: CM-ResPerson

•

Commercial: CM-ComBusiness

•

Industrial: CM-IndBusiness

Install Events : Install event business objects for each type of customer, as follows:

•

Residential: CM-ResidentialMeterInstallEvent

•

Commercial: CM-CommercialMeterInstallEvent

•

Industrial: CM-IndustrialMeterInstallEvent

Service Providers : Service provider business objects for each head-end system, and for the billing system, as follows:

•

Head-End System: CM-HeadEndMRU (Meters R Us)

•

Head-End System: CM-HeadEndMT (Meter Tech, Inc.)

•

Billing System: CM-ExternalAppCCB

Devices and Measuring Components

For devices and measuring components, we would need to create the following:

Devices : Device business objects for each type of meter, as follows:

•

Residential: CM-ScalarRegister

•

Install Event BO: CM-ResidentialInstallEvent (see above)

•

Valid Command Request BO: D1-DeviceCommission, etc.* (see below)

•

Commercial: CM-IntChanScalarReg

•

Install Event BO: CM-CommercialInstallEvent (see above)

•

Valid Command Request BO: D1-DeviceCommission, etc.* (see below)

•

Industrial: CM-Interval2Channels

•

Install Event BO: CM-IndustrialInstallEvent (see above)

•

Valid Command Request BO: D1-DeviceCommission, etc.* (see below)

*Note : Each device business object should specify the specific commands available for devices based on that business object

Measuring Components : Measuring component business objects for scalar registers and/or interval channels, as follows:

•

Residential - Scalar Register: CM-ResScalarRegister

•

Commercial/Industrial - Interval Channel: CM-IntervalChannel (used for both commercial and industrial meters)

•

Commercial - Scalar Register: CM-ScalarValRegister

Measurement Data

For measurement data, we would need to create the following:

Initial Measurement Data : Initial load, estimation, and manual initial measurement business objects for each reading/measurement type, as follows:

•

Initial Load - Interval: CM-InitialLoadIMDInterval

•

Initial Load - Scalar: CM-InitialLoadIMDScalar

•

Estimation - Interval: CM-EstimationIMDInterval

•

Estimation - Scalar: CM-EstimationIMDScalar

•

Manual - Interval: CM-ManualIMDInterval

•

Manual - Scalar: CM-ManualIMDScalar

Measurements : A single measurement business object for all final measurements, as follows:

•

Final Measurement: CM-FinalMeasurement

UOM Mapping : UOM mapping extendable lookup business objects for each head-end system, as follows:

•

MetersRUs: CM-MRUUOMMapping

•

MeterTech, Inc.: CM-MTUOMMapping

Device Events

For device events, we would need to create the following:

Device Events : Device event business objects for "standard" and "paired" device events, as follows:

•

Standard Device Event: CM-StandardDeviceEvent

•

Paired Device Event - First: CM-PairedDeviceEventFirst

•

Paired Device Event - Last: CM-PairedDeviceEventLast

Device Event Mapping : Device event mapping extendable lookup business objects for each head-end system, as follows:

•

MetersRUs: CM-MRUDeviceEventMapping

•

MeterTech, Inc.: CM-MTDeviceEventMapping

Meter Commands

For meter commands data, we would need to create the following:

Activities : For activities, this implementation can use the base package business objects, including the activity command business objects.

Outbound Communication : Outbound communication business objects for each command, as follows:

•

Commission Device: CM-InitiateCommissionDevice

•

Decommission Device: CM-InitiateDecommissionDevice

•

Device Status Check: CM-InitiateDeviceStatusCheck

•

On-Demand Read Interval: CM-InitiateOnDemandReadInterval

•

On-Demand Read Scalar: CM-InitiateOnDemandReadScalar

•

Remote Connect: CM-InitiateRemoteConnect

•

Remote Disconnect: CM-InitiateRemoteDisconnect

Inbound Communication : Inbound communication business objects for each command response, as follows:

•

Commission Device: CM-CommissionDeviceResponse

•

Decommission Device: CM-DecommissionDeviceResponse

•

Device Status Check: Cm-DeviceStatusCheckResponse

•

On-Demand Read Interval: CM-OnDemandReadIntervalResponse

•

On-Demand Read Scalar: CM-OnDemandReadScalarResponse

•

Remote Connect: CM-RemoteConnectResponse

•

Remote Disconnect: CM-RemoteDisconnectResponse

Completion Events : This implementation can use the base package completion event business objects.

Note: Because this implementation supports two head-end systems, you would need business objects for each communication for each head-end system. This list is for only one head-end system.

Design and Create Business Objects

The first step in implementing and configuring the system is to identify the business objects (and related configuration objects) needed to meet the requirements of the implementation. This section outlines the business objects and other significant configuration objects that could be created to meet the requirements of our sample implementation. This does NOT include listings of all configuration objects needed (such as individual display and maintenance UI maps, portal navigation options, etc.).

Service Points and Device Installation

For service point and device installation data, we would need to create the following:

Service Points : Service point business objects for each type of customer, as follows:

•

Residential: CM-ResidentialSP

•

Commercial: CM-CommercialSP

•

Industrial: CM-IndustrialSP

Contacts : Contact business objects for each type of customer, as follows:

•

Residential: CM-ResPerson

•

Commercial: CM-ComBusiness

•

Industrial: CM-IndBusiness

Install Events : Install event business objects for each type of customer, as follows:

•

Residential: CM-ResidentialMeterInstallEvent

•

Commercial: CM-CommercialMeterInstallEvent

•

Industrial: CM-IndustrialMeterInstallEvent

Service Providers : Service provider business objects for each head-end system, and for the billing system, as follows:

•

Head-End System: CM-HeadEndMRU (Meters R Us)

•

Head-End System: CM-HeadEndMT (Meter Tech, Inc.)

•

Billing System: CM-ExternalAppCCB

Devices and Measuring Components

For devices and measuring components, we would need to create the following:

Devices : Device business objects for each type of meter, as follows:

•

Residential: CM-ScalarRegister

•

Install Event BO: CM-ResidentialInstallEvent (see above)

•

Valid Command Request BO: D1-DeviceCommission, etc.* (see below)

•

Commercial: CM-IntChanScalarReg

•

Install Event BO: CM-CommercialInstallEvent (see above)

•

Valid Command Request BO: D1-DeviceCommission, etc.* (see below)

•

Industrial: CM-Interval2Channels

•

Install Event BO: CM-IndustrialInstallEvent (see above)

•

Valid Command Request BO: D1-DeviceCommission, etc.* (see below)

*Note : Each device business object should specify the specific commands available for devices based on that business object

Measuring Components : Measuring component business objects for scalar registers and/or interval channels, as follows:

•

Residential - Scalar Register: CM-ResScalarRegister

•

Commercial/Industrial - Interval Channel: CM-IntervalChannel (used for both commercial and industrial meters)

•

Commercial - Scalar Register: CM-ScalarValRegister

Measurement Data

For measurement data, we would need to create the following:

Initial Measurement Data : Initial load, estimation, and manual initial measurement business objects for each reading/measurement type, as follows:

•

Initial Load - Interval: CM-InitialLoadIMDInterval

•

Initial Load - Scalar: CM-InitialLoadIMDScalar

•

Estimation - Interval: CM-EstimationIMDInterval

•

Estimation - Scalar: CM-EstimationIMDScalar

•

Manual - Interval: CM-ManualIMDInterval

•

Manual - Scalar: CM-ManualIMDScalar

Measurements : A single measurement business object for all final measurements, as follows:

•

Final Measurement: CM-FinalMeasurement

UOM Mapping : UOM mapping extendable lookup business objects for each head-end system, as follows:

•

MetersRUs: CM-MRUUOMMapping

•

MeterTech, Inc.: CM-MTUOMMapping

Device Events

For device events, we would need to create the following:

Device Events : Device event business objects for "standard" and "paired" device events, as follows:

•

Standard Device Event: CM-StandardDeviceEvent

•

Paired Device Event - First: CM-PairedDeviceEventFirst

•

Paired Device Event - Last: CM-PairedDeviceEventLast

Device Event Mapping : Device event mapping extendable lookup business objects for each head-end system, as follows:

•

MetersRUs: CM-MRUDeviceEventMapping

•

MeterTech, Inc.: CM-MTDeviceEventMapping

Meter Commands

For meter commands data, we would need to create the following:

Activities : For activities, this implementation can use the base package business objects, including the activity command business objects.

Outbound Communication : Outbound communication business objects for each command, as follows:

•

Commission Device: CM-InitiateCommissionDevice

•

Decommission Device: CM-InitiateDecommissionDevice

•

Device Status Check: CM-InitiateDeviceStatusCheck

•

On-Demand Read Interval: CM-InitiateOnDemandReadInterval

•

On-Demand Read Scalar: CM-InitiateOnDemandReadScalar

•

Remote Connect: CM-InitiateRemoteConnect

•

Remote Disconnect: CM-InitiateRemoteDisconnect

Inbound Communication : Inbound communication business objects for each command response, as follows:

•

Commission Device: CM-CommissionDeviceResponse

•

Decommission Device: CM-DecommissionDeviceResponse

•

Device Status Check: Cm-DeviceStatusCheckResponse

•

On-Demand Read Interval: CM-OnDemandReadIntervalResponse

•

On-Demand Read Scalar: CM-OnDemandReadScalarResponse

•

Remote Connect: CM-RemoteConnectResponse

•

Remote Disconnect: CM-RemoteDisconnectResponse

Completion Events : This implementation can use the base package completion event business objects.

Note: Because this implementation supports two head-end systems, you would need business objects for each communication for each head-end system. This list is for only one head-end system.

Design and Create Business Objects

The first step in implementing and configuring the system is to identify the business objects (and related configuration objects) needed to meet the requirements of the implementation. This section outlines the business objects and other significant configuration objects that could be created to meet the requirements of our sample implementation. This does NOT include listings of all configuration objects needed (such as individual display and maintenance UI maps, portal navigation options, etc.).

Service Points and Device Installation

For service point and device installation data, we would need to create the following:

Service Points : Service point business objects for each type of customer, as follows:

•

Residential: CM-ResidentialSP

•

Commercial: CM-CommercialSP

•

Industrial: CM-IndustrialSP

Contacts : Contact business objects for each type of customer, as follows:

•

Residential: CM-ResPerson

•

Commercial: CM-ComBusiness

•

Industrial: CM-IndBusiness

Install Events : Install event business objects for each type of customer, as follows:

•

Residential: CM-ResidentialMeterInstallEvent

•

Commercial: CM-CommercialMeterInstallEvent

•

Industrial: CM-IndustrialMeterInstallEvent

Service Providers : Service provider business objects for each head-end system, and for the billing system, as follows:

•

Head-End System: CM-HeadEndMRU (Meters R Us)

•

Head-End System: CM-HeadEndMT (Meter Tech, Inc.)

•

Billing System: CM-ExternalAppCCB

Devices and Measuring Components

For devices and measuring components, we would need to create the following:

Devices : Device business objects for each type of meter, as follows:

•

Residential: CM-ScalarRegister

•

Install Event BO: CM-ResidentialInstallEvent (see above)

•

Valid Command Request BO: D1-DeviceCommission, etc.* (see below)

•

Commercial: CM-IntChanScalarReg

•

Install Event BO: CM-CommercialInstallEvent (see above)

•

Valid Command Request BO: D1-DeviceCommission, etc.* (see below)

•

Industrial: CM-Interval2Channels

•

Install Event BO: CM-IndustrialInstallEvent (see above)

•

Valid Command Request BO: D1-DeviceCommission, etc.* (see below)

*Note : Each device business object should specify the specific commands available for devices based on that business object

Measuring Components : Measuring component business objects for scalar registers and/or interval channels, as follows:

•

Residential - Scalar Register: CM-ResScalarRegister

•

Commercial/Industrial - Interval Channel: CM-IntervalChannel (used for both commercial and industrial meters)

•

Commercial - Scalar Register: CM-ScalarValRegister

Measurement Data

For measurement data, we would need to create the following:

Initial Measurement Data : Initial load, estimation, and manual initial measurement business objects for each reading/measurement type, as follows:

•

Initial Load - Interval: CM-InitialLoadIMDInterval

•

Initial Load - Scalar: CM-InitialLoadIMDScalar

•

Estimation - Interval: CM-EstimationIMDInterval

•

Estimation - Scalar: CM-EstimationIMDScalar

•

Manual - Interval: CM-ManualIMDInterval

•

Manual - Scalar: CM-ManualIMDScalar

Measurements : A single measurement business object for all final measurements, as follows:

•

Final Measurement: CM-FinalMeasurement

UOM Mapping : UOM mapping extendable lookup business objects for each head-end system, as follows:

•

MetersRUs: CM-MRUUOMMapping

•

MeterTech, Inc.: CM-MTUOMMapping

Device Events

For device events, we would need to create the following:

Device Events : Device event business objects for "standard" and "paired" device events, as follows:

•

Standard Device Event: CM-StandardDeviceEvent

•

Paired Device Event - First: CM-PairedDeviceEventFirst

•

Paired Device Event - Last: CM-PairedDeviceEventLast

Device Event Mapping : Device event mapping extendable lookup business objects for each head-end system, as follows:

•

MetersRUs: CM-MRUDeviceEventMapping

•

MeterTech, Inc.: CM-MTDeviceEventMapping

Meter Commands

For meter commands data, we would need to create the following:

Activities : For activities, this implementation can use the base package business objects, including the activity command business objects.

Outbound Communication : Outbound communication business objects for each command, as follows:

•

Commission Device: CM-InitiateCommissionDevice

•

Decommission Device: CM-InitiateDecommissionDevice

•

Device Status Check: CM-InitiateDeviceStatusCheck

•

On-Demand Read Interval: CM-InitiateOnDemandReadInterval

•

On-Demand Read Scalar: CM-InitiateOnDemandReadScalar

•

Remote Connect: CM-InitiateRemoteConnect

•

Remote Disconnect: CM-InitiateRemoteDisconnect

Inbound Communication : Inbound communication business objects for each command response, as follows:

•

Commission Device: CM-CommissionDeviceResponse

•

Decommission Device: CM-DecommissionDeviceResponse

•

Device Status Check: Cm-DeviceStatusCheckResponse

•

On-Demand Read Interval: CM-OnDemandReadIntervalResponse

•

On-Demand Read Scalar: CM-OnDemandReadScalarResponse

•

Remote Connect: CM-RemoteConnectResponse

•

Remote Disconnect: CM-RemoteDisconnectResponse

Completion Events : This implementation can use the base package completion event business objects.

Note: Because this implementation supports two head-end systems, you would need business objects for each communication for each head-end system. This list is for only one head-end system.

Design and Create Business Objects

The first step in implementing and configuring the system is to identify the business objects (and related configuration objects) needed to meet the requirements of the implementation. This section outlines the business objects and other significant configuration objects that could be created to meet the requirements of our sample implementation. This does NOT include listings of all configuration objects needed (such as individual display and maintenance UI maps, portal navigation options, etc.).

Service Points and Device Installation

For service point and device installation data, we would need to create the following:

Service Points : Service point business objects for each type of customer, as follows:

•

Residential: CM-ResidentialSP

•

Commercial: CM-CommercialSP

•

Industrial: CM-IndustrialSP

Contacts : Contact business objects for each type of customer, as follows:

•

Residential: CM-ResPerson

•

Commercial: CM-ComBusiness

•

Industrial: CM-IndBusiness

Install Events : Install event business objects for each type of customer, as follows:

•

Residential: CM-ResidentialMeterInstallEvent

•

Commercial: CM-CommercialMeterInstallEvent

•

Industrial: CM-IndustrialMeterInstallEvent

Service Providers : Service provider business objects for each head-end system, and for the billing system, as follows:

•

Head-End System: CM-HeadEndMRU (Meters R Us)

•

Head-End System: CM-HeadEndMT (Meter Tech, Inc.)

•

Billing System: CM-ExternalAppCCB

Devices and Measuring Components

For devices and measuring components, we would need to create the following:

Devices : Device business objects for each type of meter, as follows:

•

Residential: CM-ScalarRegister

•

Install Event BO: CM-ResidentialInstallEvent (see above)

•

Valid Command Request BO: D1-DeviceCommission, etc.* (see below)

•

Commercial: CM-IntChanScalarReg

•

Install Event BO: CM-CommercialInstallEvent (see above)

•

Valid Command Request BO: D1-DeviceCommission, etc.* (see below)

•

Industrial: CM-Interval2Channels

•

Install Event BO: CM-IndustrialInstallEvent (see above)

•

Valid Command Request BO: D1-DeviceCommission, etc.* (see below)

*Note : Each device business object should specify the specific commands available for devices based on that business object

Measuring Components : Measuring component business objects for scalar registers and/or interval channels, as follows:

•

Residential - Scalar Register: CM-ResScalarRegister

•

Commercial/Industrial - Interval Channel: CM-IntervalChannel (used for both commercial and industrial meters)

•

Commercial - Scalar Register: CM-ScalarValRegister

Measurement Data

For measurement data, we would need to create the following:

Initial Measurement Data : Initial load, estimation, and manual initial measurement business objects for each reading/measurement type, as follows:

•

Initial Load - Interval: CM-InitialLoadIMDInterval

•

Initial Load - Scalar: CM-InitialLoadIMDScalar

•

Estimation - Interval: CM-EstimationIMDInterval

•

Estimation - Scalar: CM-EstimationIMDScalar

•

Manual - Interval: CM-ManualIMDInterval

•

Manual - Scalar: CM-ManualIMDScalar

Measurements : A single measurement business object for all final measurements, as follows:

•

Final Measurement: CM-FinalMeasurement

UOM Mapping : UOM mapping extendable lookup business objects for each head-end system, as follows:

•

MetersRUs: CM-MRUUOMMapping

•

MeterTech, Inc.: CM-MTUOMMapping

Device Events

For device events, we would need to create the following:

Device Events : Device event business objects for "standard" and "paired" device events, as follows:

•

Standard Device Event: CM-StandardDeviceEvent

•

Paired Device Event - First: CM-PairedDeviceEventFirst

•

Paired Device Event - Last: CM-PairedDeviceEventLast

Device Event Mapping : Device event mapping extendable lookup business objects for each head-end system, as follows:

•

MetersRUs: CM-MRUDeviceEventMapping

•

MeterTech, Inc.: CM-MTDeviceEventMapping

Meter Commands

For meter commands data, we would need to create the following:

Activities : For activities, this implementation can use the base package business objects, including the activity command business objects.

Outbound Communication : Outbound communication business objects for each command, as follows:

•

Commission Device: CM-InitiateCommissionDevice

•

Decommission Device: CM-InitiateDecommissionDevice

•

Device Status Check: CM-InitiateDeviceStatusCheck

•

On-Demand Read Interval: CM-InitiateOnDemandReadInterval

•

On-Demand Read Scalar: CM-InitiateOnDemandReadScalar

•

Remote Connect: CM-InitiateRemoteConnect

•

Remote Disconnect: CM-InitiateRemoteDisconnect

Inbound Communication : Inbound communication business objects for each command response, as follows:

•

Commission Device: CM-CommissionDeviceResponse

•

Decommission Device: CM-DecommissionDeviceResponse

•

Device Status Check: Cm-DeviceStatusCheckResponse

•

On-Demand Read Interval: CM-OnDemandReadIntervalResponse

•

On-Demand Read Scalar: CM-OnDemandReadScalarResponse

•

Remote Connect: CM-RemoteConnectResponse

•

Remote Disconnect: CM-RemoteDisconnectResponse

Completion Events : This implementation can use the base package completion event business objects.

Note: Because this implementation supports two head-end systems, you would need business objects for each communication for each head-end system. This list is for only one head-end system.

Create Admin Data

With all of the custom business objects needed for the implementation in place, the next step would be to create admin data. This section outlines the admin data that would need to be created to meet the requirements of our sample implementation. In general these listings list only the name (or code) and description of each record to be created, and do not include details for every attribute of each record created. Where listing additional attributes is important to understanding how the data would be created, it is noted, and additional details are provided in a separate section.

The table below summarizes the common admin data needed for our implementation .

Admin Data Type

Data to Create

Activity Type

N/A (will use base package activity types)

Communication Type

One for each type of communication (outbound or inbound) as follows:

•

Commission Device / Response

Business Object (Initiate): CM-InitiateCommissionDeviceType

Business Object (Response): CM-CommissionDeviceResponseType

•

Decommission Device / Response

Business Object (Initiate): CM-InitiateDecommissionDeviceType

Business Object (Response): CM-DecommissionDeviceResponseType

•

Device Status Check / Response

Business Object (Initiate): CM-InitiateDeviceStatusCheckType

Business Object (Response): CM-DeviceStatusCheckResponseType

•

On-Demand Read Interval / Response

Business Object (Initiate): CM-InitiateOnDemandReadIntervalType

Business Object (Response): CM-OnDemandReadIntervalResponseType

•

On-Demand Read Scalar / Response

Business Object (Initiate): CM-InitiateOnDemandReadScalarType

Business Object (Response): CM-OnDemandReadScalarResponseType

•

Remote Connect / Response

Business Object (Initiate): CM-InitiateRemoteConnectType

Business Object (Response): CM-RemoteConnectResponseType

•

Remote Disconnect / Response

Business Object (Initiate): CM-InitiateRemoteDisconnectType

Business Object (Response): CM-RemoteDisconnectResponseType

Note: The communication business objects described under "Create Business Objects" serve as the Related Transaction BO for each of the above.

Contact Type

One for each type of customer, as follows:

•

RESIDENTIAL (Residential - Person)

Business Object: CM-ResPerson

•

COMMERCIAL (Commercial - Business)

Business Object: CM-ComBusiness

•

INDUSTRIAL (Industrial - Business)

Business Object: CM-IndBusiness

Device Event Type

One for each type of device event sent from the head-end systems. Examples might include:

•

BROKEN SEAL

Business Object: CM-StandardDeviceEvent

•

OUTAGE

Business Object: CM-PairedDeviceEventFirst

•

POWER RESTORATION

Business Object: CM-PairedDeviceEventLast

•

TAMPER

Business Object: CM-StandardDeviceEvent

Exception Type

One for each VEE rule, as appropriate.

Factor

N/A

Market

Single market:

•

SMALLTOWNUSA

Measurement Cycle

Twenty cycles for each type of customer, as follows:

•

RESMC01, RESMC02, ..., RESMC20

•

COMMC01, COMMC02, ..., COMMC20

•

INDMC01, INDMC02, ..., INDMC20

Measurement Cycle Schedule

One per measurement cycle per month, as follows:

•

RESMC01:

•

Scheduled Selection Date: 08/02/2010

•

Expected Work Date: 08/03/2010

•

RESMC02:

•

Scheduled Selection Date: 08/03/2010

•

Expected Work Date: 08/04/2010

•

RESMC03:

•

...

Service Provider

One for each head-end system, and one for the billing system, as follows:

•

METERSRUS (Meters R Us)

Business Object: CM-HeadEndMRU

•

METERTECH (MeterTech, Inc.)

Business Object: CM-HeadEndMT

•

OUCCB (Oracle Utilities Customer Care and Billing)

Business Object: CM-ExternalAppCCB

* See Service Providers for additional details.

Service Quantity Identifier

N/A

Service Type

Single service type:

•

ELECTRIC (Electric)

Manufacturer

One for each manufacturer, as follows:

•

METERSRUS (Meters R Us)

•

Models: RES2010

•

METERTECH (MeterTech, Inc.)

•

Models: COM2010, IND2010

Unit of Measure

One for each type of metered usage and for calculated usage, as follows:

•

KVA (calculated)

•

KVAR (used in KVA calculation)

•

KVARH (measured)

•

KW (derived)

•

KWH (measured)

* All UOMs use the ELECTRIC service type.

Measuring Component Type

Five measuring component types, as follows:

•

RESSCALAR (Residential Scalar Register)

Business Object: CM-ResScalarRegister

•

COMINTERVAL (Commercial Interval Channel)

Business Object: CM-IntervalChannel

•

COMSCALAR (Commercial Scalar Register)

Business Object: CM-ScalarValRegister

•

INDINTERVALKVARH (Industrial KVARH Interval Channel)

Business Object: CM-IntervalChannel

•

INDINTERVALKWH (Industrial KWH Interval Channel)

Business Object: CM-IntervalChannel

* All measuring component types use the ELECTRIC service type. See Measuring Component Types for additional details.

Device Configuration Type

One device configuration type for each type of meter installed, as follows:

•

RESDVCCFG (Residential Device Configuration)

Valid Measuring Component Types:

•

RESSCALAR (Residential Scalar Register)

•

COMDVCCFG (Commercial Device Configuration)

Valid Measuring Component Types:

•

COMSCALAR (Commercial Scalar Register)

•

COMINTERVAL (Commercial Interval Channel)

•

INDDVCCFG (Industrial Device Configuration)

Valid Measuring Component Types:

•

INDINTERVALKVARH (Industrial KVARH Interval Channel)

•

INDINTERVALKWH (Industrial KWH Interval Channel)

*All device configuration types use the ELECTRIC service type.

Device Type

One device type for each type of meter installed, as follows:

•

RESDVC (Residential Device)

Business Object: CM-ScalarRegister

Valid Device Configuration Types:

•

RESDVCCFG (Residential Device Configurations)

•

COMDVC (Commercial Device)

Business Object: CM-IntChanScalarReg

Valid Device Configuration Types:

•

COMDVCCFG (Commercial Device Configurations)

•

INDDVC (Industrial Device)

Business Object: CM-Interval2Channels

Valid Device Configuration Types:

•

INDDVCCFG (Industrial Device Configurations)

*All device types use the ELECTRIC service type.

Service Point Type

One for each type of customer rule, as follows:

•

RESIDENTIAL (Residential)

Business Object: CM-ResidentialSP

Valid Device Types:

•

RESDVC (Residential Devices)

•

COMMERCIAL (Commercial)

Business Object: CM-CommercialSP

Valid Device Types:

•

COMDVC (Commercial Devices)

•

INDUSTRIAL (Industrial)

Business Object: CM-IndustrialSP

Valid Device Types:

•

INDDVC (Industrial Devices)

* All service point types use ELECTRIC service type

Additional Details

This section provides additional details related to the admin data described above. Not all attributes are listed for all types of data.

Service Providers

This section provides additional details for each of the service providers listed above.

Service Provider : METERSRUS

•

Business Object: CM-HeadEndMRU

•

Description: Meters R Us

•

External Reference ID: HE-MRU

•

Our Name/ID in Their System: HE-MRU-11

•

Processing Methods List:

Processing Role

Processing Method

Default Processing Method

Override Processing Methods

Initial Measurement Creation

How To Create MC Related Information

CM-InitialLoadIMDScalar (Business Object)

MC Type: Residential Scalar Register (RESSCALAR)

Business Object: CM-InitialLoadIMDScalar

Device Commission

How to Create OB Communication / Send OB Message

CM-InitiateCommissionDevice (Business Object)

Device Decomission

How to Create OB Communication / Send OB Message

CM-InitiateDecommissionDevice (Business Object)

Device Event Mapping

How to Process Device Related Information

CM-MRSDeviceEventMapping

(Business Object)

Device Status Check

How to Create OB Communication / Send OB Message

CM-InitiateDeviceStatusCheck (Business Object)

On-Demand Read (Interval)

How to Create OB Communication / Send OB Message

CM-InitiateOnDemandReadInterval (Business Object)

On-Demand Read (Scalar)

How to Create OB Communication / Send OB Message

CM-InitiateOnDemandReadScalar (Business Object)

Remote Connect

How to Create OB Communication / Send OB Message

CM-InitiateRemoteConnect (Business Object)

Remote Disconnect

How to Create OB Communication / Send OB Message

CM-InitiateRemoteDisconnect (Business Object)

UOM Mapping

How to Process Device Related Information

CM-MRUUOMMapping (Business Object)

Service Provider : METERTECH

•

Business Object: CM-HeadEndMT

•

Description: MeterTech, Inc.

•

External Reference ID: HE-MTECH

•

Our Name/ID in Their System: HE-MTECH-11

•

Processing Methods List:

Processing Role

Processing Method

Default Processing Method

Override Processing Methods

Initial Measurement Creation

How To Create MC Related Information

CM-InitialLoadIMDInterval (Business Object)

MC Type: Residential Scalar Register (RESSCALAR) / Business Object: CM-InitialLoadIMDScalar

MC Type: Commercial Scalar Register (COMSCALAR) / Business Object: CM-InitialLoadIMDScalar

Device Commission

How to Create OB Communication / Send OB Message

CM-InitiateCommissionDevice (Business Object)

Device Decomission

How to Create OB Communication / Send OB Message

CM-InitiateDecommissionDevice (Business Object)

Device Event Mapping

How to Process Device Related Information

CM-MTDeviceEventMapping

(Business Object)

Device Status Check

How to Create OB Communication / Send OB Message

CM-InitiateDeviceStatusCheck (Business Object)

On-Demand Read (Interval)

How to Create OB Communication / Send OB Message

CM-InitiateOnDemandReadInterval (Business Object)

On-Demand Read (Scalar)

How to Create OB Communication / Send OB Message

CM-InitiateOnDemandReadScalar (Business Object)

Remote Connect

How to Create OB Communication / Send OB Message

CM-InitiateRemoteConnect (Business Object)

Remote Disconnect

How to Create OB Communication / Send OB Message

CM-InitiateRemoteDisconnect (Business Object)

UOM Mapping

How to Process Device Related Information

CM-MTUOMMapping (Business Object)

Service Provider : OUCCB

•

Business Object: CM-ExternalAppCCB

•

Description: Oracle Utilities Customer Care and Billing

•

External Reference ID: EXT-CCB

•

Our Name/ID in Their System: EXT-CCB-11

•

Processing Methods List:

Measuring Component Types

This section provides additional details for each of the measuring component types listed above.

Measuring Component Type : RESSCALAR

•

Description: Residential Scalar Register

•

Measuring Component Business Object: CM-ResScalarRegister

•

Measurement Business Object: CM-FinalMeasurement

•

Service Type: Electric

•

Value Identifiers:

Value Identifier Type

Short-Hand Description

UOM

Measurement

KWH

KWH

•

Valid VEE Groups:

•

Initial Load VEE Group - Scalar (SCALAR_MCS)

•

Fallback VEE Groups:

•

Initial Load: Initial Load VEE Group - Scalar (SCALAR_MCS)

Measuring Component Type : COMINTERVAL

•

Description: Commercial Interval Channel

•

Measuring Component Business Object: CM-IntervalChannel

•

Measurement Business Object: CM-FinalMeasurement

•

Service Type: Electric

•

Value Identifiers:

Value Identifier Type

Short-Hand Description

UOM

Measurement

KWH

KWH

•

Valid VEE Groups:

•

Initial Load VEE Group - Commercial Interval (COM_INTD_MCS)

•

Fallback VEE Groups:

•

Initial Load: Initial Load VEE Group - Commercial Interval (COM_INTD_MCS)

Measuring Component Type : COMSCALAR

•

Description: Commercial Scalar Register

•

Measuring Component Business Object: CM-ScalarValRegister

•

Measurement Business Object: CM-FinalMeasurement

•

Service Type: Electric

•

Value Identifiers:

Value Identifier Type

Short-Hand Description

UOM

Measurement

KWH

KWH

•

Valid VEE Groups:

•

Initial Load VEE Group - Scalar (SCALAR_MCS)

•

Fallback VEE Groups:

•

Initial Load: Initial Load VEE Group - Scalar (SCALAR_MCS)

Measuring Component Type : INDINTERVALKVARH

•

Description: Industrial KVARH Interval Channel

•

Business Object: CM-IntervalChannel

•

Measurement Business Object: CM-FinalMeasurement

•

Service Type: Electric

•

Value Identifiers:

Value Identifier Type

Short-Hand Description

UOM

Measurement

KVARH

KVARH

•

Valid VEE Groups:

•

Initial Load VEE Group - Industrial Interval (IND_INTD_MCS)

•

Fallback VEE Groups:

•

Initial Load: Initial Load VEE Group - Industrial Interval (IND_INTD_MCS)

Measuring Component Type : INDINTERVALKWH (Industrial KWH Interval Channel)

•

Description: Industrial KWH Interval Channel

•

Business Object: CM-IntervalChannel

•

Measurement Business Object: CM-FinalMeasurement

•

Service Type: Electric

•

Value Identifiers:

Value Identifier Type

Short-Hand Description

UOM

Measurement

KWH

KWH

•

Valid VEE Groups:

•

Initial Load VEE Group - Industrial Interval (IND_INTD_MCS)

•

Fallback VEE Groups:

•

Initial Load: Initial Load VEE Group - Industrial Interval (IND_INTD_MCS)

Create Admin Data

With all of the custom business objects needed for the implementation in place, the next step would be to create admin data. This section outlines the admin data that would need to be created to meet the requirements of our sample implementation. In general these listings list only the name (or code) and description of each record to be created, and do not include details for every attribute of each record created. Where listing additional attributes is important to understanding how the data would be created, it is noted, and additional details are provided in a separate section.

The table below summarizes the common admin data needed for our implementation .

Admin Data Type

Data to Create

Activity Type

N/A (will use base package activity types)

Communication Type

One for each type of communication (outbound or inbound) as follows:

•

Commission Device / Response

Business Object (Initiate): CM-InitiateCommissionDeviceType

Business Object (Response): CM-CommissionDeviceResponseType

•

Decommission Device / Response

Business Object (Initiate): CM-InitiateDecommissionDeviceType

Business Object (Response): CM-DecommissionDeviceResponseType

•

Device Status Check / Response

Business Object (Initiate): CM-InitiateDeviceStatusCheckType

Business Object (Response): CM-DeviceStatusCheckResponseType

•

On-Demand Read Interval / Response

Business Object (Initiate): CM-InitiateOnDemandReadIntervalType

Business Object (Response): CM-OnDemandReadIntervalResponseType

•

On-Demand Read Scalar / Response

Business Object (Initiate): CM-InitiateOnDemandReadScalarType

Business Object (Response): CM-OnDemandReadScalarResponseType

•

Remote Connect / Response

Business Object (Initiate): CM-InitiateRemoteConnectType

Business Object (Response): CM-RemoteConnectResponseType

•

Remote Disconnect / Response

Business Object (Initiate): CM-InitiateRemoteDisconnectType

Business Object (Response): CM-RemoteDisconnectResponseType

Note: The communication business objects described under "Create Business Objects" serve as the Related Transaction BO for each of the above.

Contact Type

One for each type of customer, as follows:

•

RESIDENTIAL (Residential - Person)

Business Object: CM-ResPerson

•

COMMERCIAL (Commercial - Business)

Business Object: CM-ComBusiness

•

INDUSTRIAL (Industrial - Business)

Business Object: CM-IndBusiness

Device Event Type

One for each type of device event sent from the head-end systems. Examples might include:

•

BROKEN SEAL

Business Object: CM-StandardDeviceEvent

•

OUTAGE

Business Object: CM-PairedDeviceEventFirst

•

POWER RESTORATION

Business Object: CM-PairedDeviceEventLast

•

TAMPER

Business Object: CM-StandardDeviceEvent

Exception Type

One for each VEE rule, as appropriate.

Factor

N/A

Market

Single market:

•

SMALLTOWNUSA

Measurement Cycle

Twenty cycles for each type of customer, as follows:

•

RESMC01, RESMC02, ..., RESMC20

•

COMMC01, COMMC02, ..., COMMC20

•

INDMC01, INDMC02, ..., INDMC20

Measurement Cycle Schedule

One per measurement cycle per month, as follows:

•

RESMC01:

•

Scheduled Selection Date: 08/02/2010

•

Expected Work Date: 08/03/2010

•

RESMC02:

•

Scheduled Selection Date: 08/03/2010

•

Expected Work Date: 08/04/2010

•

RESMC03:

•

...

Service Provider

One for each head-end system, and one for the billing system, as follows:

•

METERSRUS (Meters R Us)

Business Object: CM-HeadEndMRU

•

METERTECH (MeterTech, Inc.)

Business Object: CM-HeadEndMT

•

OUCCB (Oracle Utilities Customer Care and Billing)

Business Object: CM-ExternalAppCCB

* See Service Providers for additional details.

Service Quantity Identifier

N/A

Service Type

Single service type:

•

ELECTRIC (Electric)

Manufacturer

One for each manufacturer, as follows:

•

METERSRUS (Meters R Us)

•

Models: RES2010

•

METERTECH (MeterTech, Inc.)

•

Models: COM2010, IND2010

Unit of Measure

One for each type of metered usage and for calculated usage, as follows:

•

KVA (calculated)

•

KVAR (used in KVA calculation)

•

KVARH (measured)

•

KW (derived)

•

KWH (measured)

* All UOMs use the ELECTRIC service type.

Measuring Component Type

Five measuring component types, as follows:

•

RESSCALAR (Residential Scalar Register)

Business Object: CM-ResScalarRegister

•

COMINTERVAL (Commercial Interval Channel)

Business Object: CM-IntervalChannel

•

COMSCALAR (Commercial Scalar Register)

Business Object: CM-ScalarValRegister

•

INDINTERVALKVARH (Industrial KVARH Interval Channel)

Business Object: CM-IntervalChannel

•

INDINTERVALKWH (Industrial KWH Interval Channel)

Business Object: CM-IntervalChannel

* All measuring component types use the ELECTRIC service type. See Measuring Component Types for additional details.

Device Configuration Type

One device configuration type for each type of meter installed, as follows:

•

RESDVCCFG (Residential Device Configuration)

Valid Measuring Component Types:

•

RESSCALAR (Residential Scalar Register)

•

COMDVCCFG (Commercial Device Configuration)

Valid Measuring Component Types:

•

COMSCALAR (Commercial Scalar Register)

•

COMINTERVAL (Commercial Interval Channel)

•

INDDVCCFG (Industrial Device Configuration)

Valid Measuring Component Types:

•

INDINTERVALKVARH (Industrial KVARH Interval Channel)

•

INDINTERVALKWH (Industrial KWH Interval Channel)

*All device configuration types use the ELECTRIC service type.

Device Type

One device type for each type of meter installed, as follows:

•

RESDVC (Residential Device)

Business Object: CM-ScalarRegister

Valid Device Configuration Types:

•

RESDVCCFG (Residential Device Configurations)

•

COMDVC (Commercial Device)

Business Object: CM-IntChanScalarReg

Valid Device Configuration Types:

•

COMDVCCFG (Commercial Device Configurations)

•

INDDVC (Industrial Device)

Business Object: CM-Interval2Channels

Valid Device Configuration Types:

•

INDDVCCFG (Industrial Device Configurations)

*All device types use the ELECTRIC service type.

Service Point Type

One for each type of customer rule, as follows:

•

RESIDENTIAL (Residential)

Business Object: CM-ResidentialSP

Valid Device Types:

•

RESDVC (Residential Devices)

•

COMMERCIAL (Commercial)

Business Object: CM-CommercialSP

Valid Device Types:

•

COMDVC (Commercial Devices)

•

INDUSTRIAL (Industrial)

Business Object: CM-IndustrialSP

Valid Device Types:

•

INDDVC (Industrial Devices)

* All service point types use ELECTRIC service type

Additional Details

This section provides additional details related to the admin data described above. Not all attributes are listed for all types of data.

Service Providers

This section provides additional details for each of the service providers listed above.

Service Provider : METERSRUS

•

Business Object: CM-HeadEndMRU

•

Description: Meters R Us

•

External Reference ID: HE-MRU

•

Our Name/ID in Their System: HE-MRU-11

•

Processing Methods List:

Processing Role

Processing Method

Default Processing Method

Override Processing Methods

Initial Measurement Creation

How To Create MC Related Information

CM-InitialLoadIMDScalar (Business Object)

MC Type: Residential Scalar Register (RESSCALAR)

Business Object: CM-InitialLoadIMDScalar

Device Commission

How to Create OB Communication / Send OB Message

CM-InitiateCommissionDevice (Business Object)

Device Decomission

How to Create OB Communication / Send OB Message

CM-InitiateDecommissionDevice (Business Object)

Device Event Mapping

How to Process Device Related Information

CM-MRSDeviceEventMapping

(Business Object)

Device Status Check

How to Create OB Communication / Send OB Message

CM-InitiateDeviceStatusCheck (Business Object)

On-Demand Read (Interval)

How to Create OB Communication / Send OB Message

CM-InitiateOnDemandReadInterval (Business Object)

On-Demand Read (Scalar)

How to Create OB Communication / Send OB Message

CM-InitiateOnDemandReadScalar (Business Object)

Remote Connect

How to Create OB Communication / Send OB Message

CM-InitiateRemoteConnect (Business Object)

Remote Disconnect

How to Create OB Communication / Send OB Message

CM-InitiateRemoteDisconnect (Business Object)

UOM Mapping

How to Process Device Related Information

CM-MRUUOMMapping (Business Object)

Service Provider : METERTECH

•

Business Object: CM-HeadEndMT

•

Description: MeterTech, Inc.

•

External Reference ID: HE-MTECH

•

Our Name/ID in Their System: HE-MTECH-11

•

Processing Methods List:

Processing Role

Processing Method

Default Processing Method

Override Processing Methods

Initial Measurement Creation

How To Create MC Related Information

CM-InitialLoadIMDInterval (Business Object)

MC Type: Residential Scalar Register (RESSCALAR) / Business Object: CM-InitialLoadIMDScalar

MC Type: Commercial Scalar Register (COMSCALAR) / Business Object: CM-InitialLoadIMDScalar

Device Commission

How to Create OB Communication / Send OB Message

CM-InitiateCommissionDevice (Business Object)

Device Decomission

How to Create OB Communication / Send OB Message

CM-InitiateDecommissionDevice (Business Object)

Device Event Mapping

How to Process Device Related Information

CM-MTDeviceEventMapping

(Business Object)

Device Status Check

How to Create OB Communication / Send OB Message

CM-InitiateDeviceStatusCheck (Business Object)

On-Demand Read (Interval)

How to Create OB Communication / Send OB Message

CM-InitiateOnDemandReadInterval (Business Object)

On-Demand Read (Scalar)

How to Create OB Communication / Send OB Message

CM-InitiateOnDemandReadScalar (Business Object)

Remote Connect

How to Create OB Communication / Send OB Message

CM-InitiateRemoteConnect (Business Object)

Remote Disconnect

How to Create OB Communication / Send OB Message

CM-InitiateRemoteDisconnect (Business Object)

UOM Mapping

How to Process Device Related Information

CM-MTUOMMapping (Business Object)

Service Provider : OUCCB

•

Business Object: CM-ExternalAppCCB

•

Description: Oracle Utilities Customer Care and Billing

•

External Reference ID: EXT-CCB

•

Our Name/ID in Their System: EXT-CCB-11

•

Processing Methods List:

Measuring Component Types

This section provides additional details for each of the measuring component types listed above.

Measuring Component Type : RESSCALAR

•

Description: Residential Scalar Register

•

Measuring Component Business Object: CM-ResScalarRegister

•

Measurement Business Object: CM-FinalMeasurement

•

Service Type: Electric

•

Value Identifiers:

Value Identifier Type

Short-Hand Description

UOM

Measurement

KWH

KWH

•

Valid VEE Groups:

•

Initial Load VEE Group - Scalar (SCALAR_MCS)

•

Fallback VEE Groups:

•

Initial Load: Initial Load VEE Group - Scalar (SCALAR_MCS)

Measuring Component Type : COMINTERVAL

•

Description: Commercial Interval Channel

•

Measuring Component Business Object: CM-IntervalChannel

•

Measurement Business Object: CM-FinalMeasurement

•

Service Type: Electric

•

Value Identifiers:

Value Identifier Type

Short-Hand Description

UOM

Measurement

KWH

KWH

•

Valid VEE Groups:

•

Initial Load VEE Group - Commercial Interval (COM_INTD_MCS)

•

Fallback VEE Groups:

•

Initial Load: Initial Load VEE Group - Commercial Interval (COM_INTD_MCS)

Measuring Component Type : COMSCALAR

•

Description: Commercial Scalar Register

•

Measuring Component Business Object: CM-ScalarValRegister

•

Measurement Business Object: CM-FinalMeasurement

•

Service Type: Electric

•

Value Identifiers:

Value Identifier Type

Short-Hand Description

UOM

Measurement

KWH

KWH

•

Valid VEE Groups:

•

Initial Load VEE Group - Scalar (SCALAR_MCS)

•

Fallback VEE Groups:

•

Initial Load: Initial Load VEE Group - Scalar (SCALAR_MCS)

Measuring Component Type : INDINTERVALKVARH

•

Description: Industrial KVARH Interval Channel

•

Business Object: CM-IntervalChannel

•

Measurement Business Object: CM-FinalMeasurement

•

Service Type: Electric

•

Value Identifiers:

Value Identifier Type

Short-Hand Description

UOM

Measurement

KVARH

KVARH

•

Valid VEE Groups:

•

Initial Load VEE Group - Industrial Interval (IND_INTD_MCS)

•

Fallback VEE Groups:

•

Initial Load: Initial Load VEE Group - Industrial Interval (IND_INTD_MCS)

Measuring Component Type : INDINTERVALKWH (Industrial KWH Interval Channel)

•

Description: Industrial KWH Interval Channel

•

Business Object: CM-IntervalChannel

•

Measurement Business Object: CM-FinalMeasurement

•

Service Type: Electric

•

Value Identifiers:

Value Identifier Type

Short-Hand Description

UOM

Measurement

KWH

KWH

•

Valid VEE Groups:

•

Initial Load VEE Group - Industrial Interval (IND_INTD_MCS)

•

Fallback VEE Groups:

•

Initial Load: Initial Load VEE Group - Industrial Interval (IND_INTD_MCS)

Create Master Data

In this last step, we would create the actual master data (individual devices, service points, etc.) for the implementation. For purposes of this section, only a single example of each type of data is presented.

Contacts

A typical residential contact might look like this:

Residential - Person:

•

Information: John Smith / 555-555-5555

•

Contact Type: Residential - Person (RESIDENTIAL)

•

Name: John Smith

•

Home Phone: 555-555-5555

Service Points

A typical commercial service point might look like this:

Commercial Service Point:

•

Information: 35 York Street, Burlington, MA, 01803, US / Commercial / Active

•

Service Point Type: Commercial (COMMERCIAL)

•

Status: Active

•

Time Zone: US - Eastern Time

•

Market: Small Town USA

•

Main Contact: Phillip Jones

•

Address:

•

Country: United States

•

Postal Code: 01803

•

Street Address: 35 York Street

•

City: Burlington

•

State: MA

•

Measurement Cycle:

•

Measurement Cycle: Commercial Cycle 01 (COMMC01)

•

Route: Route 2

•

Sequence: 10

Devices

A typical industrial device might look like this:

Industrial Device:

•

Information: 123456 / Industrial Device / Install Date/Time: 08-01-2010 12:00 AM / Pending / MeterTech, Inc. / Active

•

Device Type: Industrial Device (INDDVC)

•

Serial Number: 123456

•

Internal Meter Number: 654321

•

Pallet Number: 123456

•

Manufacturer: MeterTech, Inc.

•

Model: IND2010

•

Incoming Data Shift: Shifted

•

Arming Required: Arming Required

•

Head-End System: MeterTech, Inc. (METERTECH)

•

Status: Active

Device Configurations

A typical industrial device configuration might look like this:

Industrial Device Configuration:

•

Information: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Device Configuration Type: Industrial Device Configuration (INDDVCCFG)

•

Device: 123456 / Industrial Device / Install Date/Time: 08-01-2010 12:00 AM / Pending / MeterTech, Inc. / Active

•

Effective Date/Time: 08-01-2010 12:00 AM

•

Time Zone: US - Eastern Time

•

Status: Active

Measuring Components

Typical industrial measuring components might look like this:

KVARH Interval Channel:

•

Information: 123456 / 2 / Industrial KVARH Interval Channel

•

Measuring Component Type: Industrial KVARH Interval Channel (INDINTERVALKVARH)

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Consumption Reference Measuring Component: N/A

•

How to Use: Consumptive

•

Number of Digits Left: 5

•

Number of Digits Right: 2

•

Channel Multiplier: 1.000

•

Latest Read Date/Time: N/A

•

Channel ID: 2

KWH Interval Channel:

•

Information: 123456 / 1 / Industrial KWH Interval Channel

•

Measuring Component Type: Industrial KWH Interval Channel (INDINTERVALKWH)

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Consumption Reference Measuring Component: N/A

•

How to Use: Consumptive

•

Number of Digits Left: 5

•

Number of Digits Right: 2

•

Channel Multiplier: 1.000

•

Latest Read Date/Time: N/A

•

Channel ID: 1

Install Events

A typical industrial installation event might look like this:

Industrial Install Event:

•

Information: Install Date/Time: 08-01-2010 / On

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Service Point: 47 North Street, Burlington, MA, 01803, US / Industrial / Active

•

Status: On

•

Installation Date/Time: 08-01-2010

•

Installation Constant: 1.00000

•

Device On/Off Status: On

•

On/Off History: N/A

Other Components

Note that for each communication you create, you must also create corresponding components of the following types used to send/received messages from the middleware. These include:

Outbound Communications

•

Outbound Message Type

•

XAI Sender (XAI)

•

External System

Inbound Communications

•

XAI Inbound Service

See Chapter 9 : Integrating Oracle Utilities Smart Grid Gateway with Other Systems for more information about creating these components when configuring communications with head-end systems and middleware.

Create Master Data

In this last step, we would create the actual master data (individual devices, service points, etc.) for the implementation. For purposes of this section, only a single example of each type of data is presented.

Contacts

A typical residential contact might look like this:

Residential - Person:

•

Information: John Smith / 555-555-5555

•

Contact Type: Residential - Person (RESIDENTIAL)

•

Name: John Smith

•

Home Phone: 555-555-5555

Service Points

A typical commercial service point might look like this:

Commercial Service Point:

•

Information: 35 York Street, Burlington, MA, 01803, US / Commercial / Active

•

Service Point Type: Commercial (COMMERCIAL)

•

Status: Active

•

Time Zone: US - Eastern Time

•

Market: Small Town USA

•

Main Contact: Phillip Jones

•

Address:

•

Country: United States

•

Postal Code: 01803

•

Street Address: 35 York Street

•

City: Burlington

•

State: MA

•

Measurement Cycle:

•

Measurement Cycle: Commercial Cycle 01 (COMMC01)

•

Route: Route 2

•

Sequence: 10

Devices

A typical industrial device might look like this:

Industrial Device:

•

Information: 123456 / Industrial Device / Install Date/Time: 08-01-2010 12:00 AM / Pending / MeterTech, Inc. / Active

•

Device Type: Industrial Device (INDDVC)

•

Serial Number: 123456

•

Internal Meter Number: 654321

•

Pallet Number: 123456

•

Manufacturer: MeterTech, Inc.

•

Model: IND2010

•

Incoming Data Shift: Shifted

•

Arming Required: Arming Required

•

Head-End System: MeterTech, Inc. (METERTECH)

•

Status: Active

Device Configurations

A typical industrial device configuration might look like this:

Industrial Device Configuration:

•

Information: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Device Configuration Type: Industrial Device Configuration (INDDVCCFG)

•

Device: 123456 / Industrial Device / Install Date/Time: 08-01-2010 12:00 AM / Pending / MeterTech, Inc. / Active

•

Effective Date/Time: 08-01-2010 12:00 AM

•

Time Zone: US - Eastern Time

•

Status: Active

Measuring Components

Typical industrial measuring components might look like this:

KVARH Interval Channel:

•

Information: 123456 / 2 / Industrial KVARH Interval Channel

•

Measuring Component Type: Industrial KVARH Interval Channel (INDINTERVALKVARH)

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Consumption Reference Measuring Component: N/A

•

How to Use: Consumptive

•

Number of Digits Left: 5

•

Number of Digits Right: 2

•

Channel Multiplier: 1.000

•

Latest Read Date/Time: N/A

•

Channel ID: 2

KWH Interval Channel:

•

Information: 123456 / 1 / Industrial KWH Interval Channel

•

Measuring Component Type: Industrial KWH Interval Channel (INDINTERVALKWH)

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Consumption Reference Measuring Component: N/A

•

How to Use: Consumptive

•

Number of Digits Left: 5

•

Number of Digits Right: 2

•

Channel Multiplier: 1.000

•

Latest Read Date/Time: N/A

•

Channel ID: 1

Install Events

A typical industrial installation event might look like this:

Industrial Install Event:

•

Information: Install Date/Time: 08-01-2010 / On

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Service Point: 47 North Street, Burlington, MA, 01803, US / Industrial / Active

•

Status: On

•

Installation Date/Time: 08-01-2010

•

Installation Constant: 1.00000

•

Device On/Off Status: On

•

On/Off History: N/A

Other Components

Note that for each communication you create, you must also create corresponding components of the following types used to send/received messages from the middleware. These include:

Outbound Communications

•

Outbound Message Type

•

XAI Sender (XAI)

•

External System

Inbound Communications

•

XAI Inbound Service

See Chapter 9 : Integrating Oracle Utilities Smart Grid Gateway with Other Systems for more information about creating these components when configuring communications with head-end systems and middleware.

Create Master Data

In this last step, we would create the actual master data (individual devices, service points, etc.) for the implementation. For purposes of this section, only a single example of each type of data is presented.

Contacts

A typical residential contact might look like this:

Residential - Person:

•

Information: John Smith / 555-555-5555

•

Contact Type: Residential - Person (RESIDENTIAL)

•

Name: John Smith

•

Home Phone: 555-555-5555

Service Points

A typical commercial service point might look like this:

Commercial Service Point:

•

Information: 35 York Street, Burlington, MA, 01803, US / Commercial / Active

•

Service Point Type: Commercial (COMMERCIAL)

•

Status: Active

•

Time Zone: US - Eastern Time

•

Market: Small Town USA

•

Main Contact: Phillip Jones

•

Address:

•

Country: United States

•

Postal Code: 01803

•

Street Address: 35 York Street

•

City: Burlington

•

State: MA

•

Measurement Cycle:

•

Measurement Cycle: Commercial Cycle 01 (COMMC01)

•

Route: Route 2

•

Sequence: 10

Devices

A typical industrial device might look like this:

Industrial Device:

•

Information: 123456 / Industrial Device / Install Date/Time: 08-01-2010 12:00 AM / Pending / MeterTech, Inc. / Active

•

Device Type: Industrial Device (INDDVC)

•

Serial Number: 123456

•

Internal Meter Number: 654321

•

Pallet Number: 123456

•

Manufacturer: MeterTech, Inc.

•

Model: IND2010

•

Incoming Data Shift: Shifted

•

Arming Required: Arming Required

•

Head-End System: MeterTech, Inc. (METERTECH)

•

Status: Active

Device Configurations

A typical industrial device configuration might look like this:

Industrial Device Configuration:

•

Information: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Device Configuration Type: Industrial Device Configuration (INDDVCCFG)

•

Device: 123456 / Industrial Device / Install Date/Time: 08-01-2010 12:00 AM / Pending / MeterTech, Inc. / Active

•

Effective Date/Time: 08-01-2010 12:00 AM

•

Time Zone: US - Eastern Time

•

Status: Active

Measuring Components

Typical industrial measuring components might look like this:

KVARH Interval Channel:

•

Information: 123456 / 2 / Industrial KVARH Interval Channel

•

Measuring Component Type: Industrial KVARH Interval Channel (INDINTERVALKVARH)

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Consumption Reference Measuring Component: N/A

•

How to Use: Consumptive

•

Number of Digits Left: 5

•

Number of Digits Right: 2

•

Channel Multiplier: 1.000

•

Latest Read Date/Time: N/A

•

Channel ID: 2

KWH Interval Channel:

•

Information: 123456 / 1 / Industrial KWH Interval Channel

•

Measuring Component Type: Industrial KWH Interval Channel (INDINTERVALKWH)

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Consumption Reference Measuring Component: N/A

•

How to Use: Consumptive

•

Number of Digits Left: 5

•

Number of Digits Right: 2

•

Channel Multiplier: 1.000

•

Latest Read Date/Time: N/A

•

Channel ID: 1

Install Events

A typical industrial installation event might look like this:

Industrial Install Event:

•

Information: Install Date/Time: 08-01-2010 / On

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Service Point: 47 North Street, Burlington, MA, 01803, US / Industrial / Active

•

Status: On

•

Installation Date/Time: 08-01-2010

•

Installation Constant: 1.00000

•

Device On/Off Status: On

•

On/Off History: N/A

Other Components

Note that for each communication you create, you must also create corresponding components of the following types used to send/received messages from the middleware. These include:

Outbound Communications

•

Outbound Message Type

•

XAI Sender (XAI)

•

External System

Inbound Communications

•

XAI Inbound Service

See Chapter 9 : Integrating Oracle Utilities Smart Grid Gateway with Other Systems for more information about creating these components when configuring communications with head-end systems and middleware.

Create Master Data

In this last step, we would create the actual master data (individual devices, service points, etc.) for the implementation. For purposes of this section, only a single example of each type of data is presented.

Contacts

A typical residential contact might look like this:

Residential - Person:

•

Information: John Smith / 555-555-5555

•

Contact Type: Residential - Person (RESIDENTIAL)

•

Name: John Smith

•

Home Phone: 555-555-5555

Service Points

A typical commercial service point might look like this:

Commercial Service Point:

•

Information: 35 York Street, Burlington, MA, 01803, US / Commercial / Active

•

Service Point Type: Commercial (COMMERCIAL)

•

Status: Active

•

Time Zone: US - Eastern Time

•

Market: Small Town USA

•

Main Contact: Phillip Jones

•

Address:

•

Country: United States

•

Postal Code: 01803

•

Street Address: 35 York Street

•

City: Burlington

•

State: MA

•

Measurement Cycle:

•

Measurement Cycle: Commercial Cycle 01 (COMMC01)

•

Route: Route 2

•

Sequence: 10

Devices

A typical industrial device might look like this:

Industrial Device:

•

Information: 123456 / Industrial Device / Install Date/Time: 08-01-2010 12:00 AM / Pending / MeterTech, Inc. / Active

•

Device Type: Industrial Device (INDDVC)

•

Serial Number: 123456

•

Internal Meter Number: 654321

•

Pallet Number: 123456

•

Manufacturer: MeterTech, Inc.

•

Model: IND2010

•

Incoming Data Shift: Shifted

•

Arming Required: Arming Required

•

Head-End System: MeterTech, Inc. (METERTECH)

•

Status: Active

Device Configurations

A typical industrial device configuration might look like this:

Industrial Device Configuration:

•

Information: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Device Configuration Type: Industrial Device Configuration (INDDVCCFG)

•

Device: 123456 / Industrial Device / Install Date/Time: 08-01-2010 12:00 AM / Pending / MeterTech, Inc. / Active

•

Effective Date/Time: 08-01-2010 12:00 AM

•

Time Zone: US - Eastern Time

•

Status: Active

Measuring Components

Typical industrial measuring components might look like this:

KVARH Interval Channel:

•

Information: 123456 / 2 / Industrial KVARH Interval Channel

•

Measuring Component Type: Industrial KVARH Interval Channel (INDINTERVALKVARH)

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Consumption Reference Measuring Component: N/A

•

How to Use: Consumptive

•

Number of Digits Left: 5

•

Number of Digits Right: 2

•

Channel Multiplier: 1.000

•

Latest Read Date/Time: N/A

•

Channel ID: 2

KWH Interval Channel:

•

Information: 123456 / 1 / Industrial KWH Interval Channel

•

Measuring Component Type: Industrial KWH Interval Channel (INDINTERVALKWH)

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Consumption Reference Measuring Component: N/A

•

How to Use: Consumptive

•

Number of Digits Left: 5

•

Number of Digits Right: 2

•

Channel Multiplier: 1.000

•

Latest Read Date/Time: N/A

•

Channel ID: 1

Install Events

A typical industrial installation event might look like this:

Industrial Install Event:

•

Information: Install Date/Time: 08-01-2010 / On

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Service Point: 47 North Street, Burlington, MA, 01803, US / Industrial / Active

•

Status: On

•

Installation Date/Time: 08-01-2010

•

Installation Constant: 1.00000

•

Device On/Off Status: On

•

On/Off History: N/A

Other Components

Note that for each communication you create, you must also create corresponding components of the following types used to send/received messages from the middleware. These include:

Outbound Communications

•

Outbound Message Type

•

XAI Sender (XAI)

•

External System

Inbound Communications

•

XAI Inbound Service

See Chapter 9 : Integrating Oracle Utilities Smart Grid Gateway with Other Systems for more information about creating these components when configuring communications with head-end systems and middleware.

Create Master Data

In this last step, we would create the actual master data (individual devices, service points, etc.) for the implementation. For purposes of this section, only a single example of each type of data is presented.

Contacts

A typical residential contact might look like this:

Residential - Person:

•

Information: John Smith / 555-555-5555

•

Contact Type: Residential - Person (RESIDENTIAL)

•

Name: John Smith

•

Home Phone: 555-555-5555

Service Points

A typical commercial service point might look like this:

Commercial Service Point:

•

Information: 35 York Street, Burlington, MA, 01803, US / Commercial / Active

•

Service Point Type: Commercial (COMMERCIAL)

•

Status: Active

•

Time Zone: US - Eastern Time

•

Market: Small Town USA

•

Main Contact: Phillip Jones

•

Address:

•

Country: United States

•

Postal Code: 01803

•

Street Address: 35 York Street

•

City: Burlington

•

State: MA

•

Measurement Cycle:

•

Measurement Cycle: Commercial Cycle 01 (COMMC01)

•

Route: Route 2

•

Sequence: 10

Devices

A typical industrial device might look like this:

Industrial Device:

•

Information: 123456 / Industrial Device / Install Date/Time: 08-01-2010 12:00 AM / Pending / MeterTech, Inc. / Active

•

Device Type: Industrial Device (INDDVC)

•

Serial Number: 123456

•

Internal Meter Number: 654321

•

Pallet Number: 123456

•

Manufacturer: MeterTech, Inc.

•

Model: IND2010

•

Incoming Data Shift: Shifted

•

Arming Required: Arming Required

•

Head-End System: MeterTech, Inc. (METERTECH)

•

Status: Active

Device Configurations

A typical industrial device configuration might look like this:

Industrial Device Configuration:

•

Information: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Device Configuration Type: Industrial Device Configuration (INDDVCCFG)

•

Device: 123456 / Industrial Device / Install Date/Time: 08-01-2010 12:00 AM / Pending / MeterTech, Inc. / Active

•

Effective Date/Time: 08-01-2010 12:00 AM

•

Time Zone: US - Eastern Time

•

Status: Active

Measuring Components

Typical industrial measuring components might look like this:

KVARH Interval Channel:

•

Information: 123456 / 2 / Industrial KVARH Interval Channel

•

Measuring Component Type: Industrial KVARH Interval Channel (INDINTERVALKVARH)

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Consumption Reference Measuring Component: N/A

•

How to Use: Consumptive

•

Number of Digits Left: 5

•

Number of Digits Right: 2

•

Channel Multiplier: 1.000

•

Latest Read Date/Time: N/A

•

Channel ID: 2

KWH Interval Channel:

•

Information: 123456 / 1 / Industrial KWH Interval Channel

•

Measuring Component Type: Industrial KWH Interval Channel (INDINTERVALKWH)

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Consumption Reference Measuring Component: N/A

•

How to Use: Consumptive

•

Number of Digits Left: 5

•

Number of Digits Right: 2

•

Channel Multiplier: 1.000

•

Latest Read Date/Time: N/A

•

Channel ID: 1

Install Events

A typical industrial installation event might look like this:

Industrial Install Event:

•

Information: Install Date/Time: 08-01-2010 / On

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Service Point: 47 North Street, Burlington, MA, 01803, US / Industrial / Active

•

Status: On

•

Installation Date/Time: 08-01-2010

•

Installation Constant: 1.00000

•

Device On/Off Status: On

•

On/Off History: N/A

Other Components

Note that for each communication you create, you must also create corresponding components of the following types used to send/received messages from the middleware. These include:

Outbound Communications

•

Outbound Message Type

•

XAI Sender (XAI)

•

External System

Inbound Communications

•

XAI Inbound Service

See Chapter 9 : Integrating Oracle Utilities Smart Grid Gateway with Other Systems for more information about creating these components when configuring communications with head-end systems and middleware.

Create Master Data

In this last step, we would create the actual master data (individual devices, service points, etc.) for the implementation. For purposes of this section, only a single example of each type of data is presented.

Contacts

A typical residential contact might look like this:

Residential - Person:

•

Information: John Smith / 555-555-5555

•

Contact Type: Residential - Person (RESIDENTIAL)

•

Name: John Smith

•

Home Phone: 555-555-5555

Service Points

A typical commercial service point might look like this:

Commercial Service Point:

•

Information: 35 York Street, Burlington, MA, 01803, US / Commercial / Active

•

Service Point Type: Commercial (COMMERCIAL)

•

Status: Active

•

Time Zone: US - Eastern Time

•

Market: Small Town USA

•

Main Contact: Phillip Jones

•

Address:

•

Country: United States

•

Postal Code: 01803

•

Street Address: 35 York Street

•

City: Burlington

•

State: MA

•

Measurement Cycle:

•

Measurement Cycle: Commercial Cycle 01 (COMMC01)

•

Route: Route 2

•

Sequence: 10

Devices

A typical industrial device might look like this:

Industrial Device:

•

Information: 123456 / Industrial Device / Install Date/Time: 08-01-2010 12:00 AM / Pending / MeterTech, Inc. / Active

•

Device Type: Industrial Device (INDDVC)

•

Serial Number: 123456

•

Internal Meter Number: 654321

•

Pallet Number: 123456

•

Manufacturer: MeterTech, Inc.

•

Model: IND2010

•

Incoming Data Shift: Shifted

•

Arming Required: Arming Required

•

Head-End System: MeterTech, Inc. (METERTECH)

•

Status: Active

Device Configurations

A typical industrial device configuration might look like this:

Industrial Device Configuration:

•

Information: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Device Configuration Type: Industrial Device Configuration (INDDVCCFG)

•

Device: 123456 / Industrial Device / Install Date/Time: 08-01-2010 12:00 AM / Pending / MeterTech, Inc. / Active

•

Effective Date/Time: 08-01-2010 12:00 AM

•

Time Zone: US - Eastern Time

•

Status: Active

Measuring Components

Typical industrial measuring components might look like this:

KVARH Interval Channel:

•

Information: 123456 / 2 / Industrial KVARH Interval Channel

•

Measuring Component Type: Industrial KVARH Interval Channel (INDINTERVALKVARH)

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Consumption Reference Measuring Component: N/A

•

How to Use: Consumptive

•

Number of Digits Left: 5

•

Number of Digits Right: 2

•

Channel Multiplier: 1.000

•

Latest Read Date/Time: N/A

•

Channel ID: 2

KWH Interval Channel:

•

Information: 123456 / 1 / Industrial KWH Interval Channel

•

Measuring Component Type: Industrial KWH Interval Channel (INDINTERVALKWH)

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Consumption Reference Measuring Component: N/A

•

How to Use: Consumptive

•

Number of Digits Left: 5

•

Number of Digits Right: 2

•

Channel Multiplier: 1.000

•

Latest Read Date/Time: N/A

•

Channel ID: 1

Install Events

A typical industrial installation event might look like this:

Industrial Install Event:

•

Information: Install Date/Time: 08-01-2010 / On

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Service Point: 47 North Street, Burlington, MA, 01803, US / Industrial / Active

•

Status: On

•

Installation Date/Time: 08-01-2010

•

Installation Constant: 1.00000

•

Device On/Off Status: On

•

On/Off History: N/A

Other Components

Note that for each communication you create, you must also create corresponding components of the following types used to send/received messages from the middleware. These include:

Outbound Communications

•

Outbound Message Type

•

XAI Sender (XAI)

•

External System

Inbound Communications

•

XAI Inbound Service

See Chapter 9 : Integrating Oracle Utilities Smart Grid Gateway with Other Systems for more information about creating these components when configuring communications with head-end systems and middleware.

Create Master Data

In this last step, we would create the actual master data (individual devices, service points, etc.) for the implementation. For purposes of this section, only a single example of each type of data is presented.

Contacts

A typical residential contact might look like this:

Residential - Person:

•

Information: John Smith / 555-555-5555

•

Contact Type: Residential - Person (RESIDENTIAL)

•

Name: John Smith

•

Home Phone: 555-555-5555

Service Points

A typical commercial service point might look like this:

Commercial Service Point:

•

Information: 35 York Street, Burlington, MA, 01803, US / Commercial / Active

•

Service Point Type: Commercial (COMMERCIAL)

•

Status: Active

•

Time Zone: US - Eastern Time

•

Market: Small Town USA

•

Main Contact: Phillip Jones

•

Address:

•

Country: United States

•

Postal Code: 01803

•

Street Address: 35 York Street

•

City: Burlington

•

State: MA

•

Measurement Cycle:

•

Measurement Cycle: Commercial Cycle 01 (COMMC01)

•

Route: Route 2

•

Sequence: 10

Devices

A typical industrial device might look like this:

Industrial Device:

•

Information: 123456 / Industrial Device / Install Date/Time: 08-01-2010 12:00 AM / Pending / MeterTech, Inc. / Active

•

Device Type: Industrial Device (INDDVC)

•

Serial Number: 123456

•

Internal Meter Number: 654321

•

Pallet Number: 123456

•

Manufacturer: MeterTech, Inc.

•

Model: IND2010

•

Incoming Data Shift: Shifted

•

Arming Required: Arming Required

•

Head-End System: MeterTech, Inc. (METERTECH)

•

Status: Active

Device Configurations

A typical industrial device configuration might look like this:

Industrial Device Configuration:

•

Information: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Device Configuration Type: Industrial Device Configuration (INDDVCCFG)

•

Device: 123456 / Industrial Device / Install Date/Time: 08-01-2010 12:00 AM / Pending / MeterTech, Inc. / Active

•

Effective Date/Time: 08-01-2010 12:00 AM

•

Time Zone: US - Eastern Time

•

Status: Active

Measuring Components

Typical industrial measuring components might look like this:

KVARH Interval Channel:

•

Information: 123456 / 2 / Industrial KVARH Interval Channel

•

Measuring Component Type: Industrial KVARH Interval Channel (INDINTERVALKVARH)

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Consumption Reference Measuring Component: N/A

•

How to Use: Consumptive

•

Number of Digits Left: 5

•

Number of Digits Right: 2

•

Channel Multiplier: 1.000

•

Latest Read Date/Time: N/A

•

Channel ID: 2

KWH Interval Channel:

•

Information: 123456 / 1 / Industrial KWH Interval Channel

•

Measuring Component Type: Industrial KWH Interval Channel (INDINTERVALKWH)

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Consumption Reference Measuring Component: N/A

•

How to Use: Consumptive

•

Number of Digits Left: 5

•

Number of Digits Right: 2

•

Channel Multiplier: 1.000

•

Latest Read Date/Time: N/A

•

Channel ID: 1

Install Events

A typical industrial installation event might look like this:

Industrial Install Event:

•

Information: Install Date/Time: 08-01-2010 / On

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Service Point: 47 North Street, Burlington, MA, 01803, US / Industrial / Active

•

Status: On

•

Installation Date/Time: 08-01-2010

•

Installation Constant: 1.00000

•

Device On/Off Status: On

•

On/Off History: N/A

Other Components

Note that for each communication you create, you must also create corresponding components of the following types used to send/received messages from the middleware. These include:

Outbound Communications

•

Outbound Message Type

•

XAI Sender (XAI)

•

External System

Inbound Communications

•

XAI Inbound Service

See Chapter 9 : Integrating Oracle Utilities Smart Grid Gateway with Other Systems for more information about creating these components when configuring communications with head-end systems and middleware.

Create Master Data

In this last step, we would create the actual master data (individual devices, service points, etc.) for the implementation. For purposes of this section, only a single example of each type of data is presented.

Contacts

A typical residential contact might look like this:

Residential - Person:

•

Information: John Smith / 555-555-5555

•

Contact Type: Residential - Person (RESIDENTIAL)

•

Name: John Smith

•

Home Phone: 555-555-5555

Service Points

A typical commercial service point might look like this:

Commercial Service Point:

•

Information: 35 York Street, Burlington, MA, 01803, US / Commercial / Active

•

Service Point Type: Commercial (COMMERCIAL)

•

Status: Active

•

Time Zone: US - Eastern Time

•

Market: Small Town USA

•

Main Contact: Phillip Jones

•

Address:

•

Country: United States

•

Postal Code: 01803

•

Street Address: 35 York Street

•

City: Burlington

•

State: MA

•

Measurement Cycle:

•

Measurement Cycle: Commercial Cycle 01 (COMMC01)

•

Route: Route 2

•

Sequence: 10

Devices

A typical industrial device might look like this:

Industrial Device:

•

Information: 123456 / Industrial Device / Install Date/Time: 08-01-2010 12:00 AM / Pending / MeterTech, Inc. / Active

•

Device Type: Industrial Device (INDDVC)

•

Serial Number: 123456

•

Internal Meter Number: 654321

•

Pallet Number: 123456

•

Manufacturer: MeterTech, Inc.

•

Model: IND2010

•

Incoming Data Shift: Shifted

•

Arming Required: Arming Required

•

Head-End System: MeterTech, Inc. (METERTECH)

•

Status: Active

Device Configurations

A typical industrial device configuration might look like this:

Industrial Device Configuration:

•

Information: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Device Configuration Type: Industrial Device Configuration (INDDVCCFG)

•

Device: 123456 / Industrial Device / Install Date/Time: 08-01-2010 12:00 AM / Pending / MeterTech, Inc. / Active

•

Effective Date/Time: 08-01-2010 12:00 AM

•

Time Zone: US - Eastern Time

•

Status: Active

Measuring Components

Typical industrial measuring components might look like this:

KVARH Interval Channel:

•

Information: 123456 / 2 / Industrial KVARH Interval Channel

•

Measuring Component Type: Industrial KVARH Interval Channel (INDINTERVALKVARH)

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Consumption Reference Measuring Component: N/A

•

How to Use: Consumptive

•

Number of Digits Left: 5

•

Number of Digits Right: 2

•

Channel Multiplier: 1.000

•

Latest Read Date/Time: N/A

•

Channel ID: 2

KWH Interval Channel:

•

Information: 123456 / 1 / Industrial KWH Interval Channel

•

Measuring Component Type: Industrial KWH Interval Channel (INDINTERVALKWH)

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Consumption Reference Measuring Component: N/A

•

How to Use: Consumptive

•

Number of Digits Left: 5

•

Number of Digits Right: 2

•

Channel Multiplier: 1.000

•

Latest Read Date/Time: N/A

•

Channel ID: 1

Install Events

A typical industrial installation event might look like this:

Industrial Install Event:

•

Information: Install Date/Time: 08-01-2010 / On

•

Device Configuration: Industrial Device / Effective Date/Time: 08-01-2010 12:00 AM / Industrial Device Configuration / 2 Measuring Component(s) / Active

•

Service Point: 47 North Street, Burlington, MA, 01803, US / Industrial / Active

•

Status: On

•

Installation Date/Time: 08-01-2010

•

Installation Constant: 1.00000

•

Device On/Off Status: On

•

On/Off History: N/A

Other Components

Note that for each communication you create, you must also create corresponding components of the following types used to send/received messages from the middleware. These include:

Outbound Communications

•

Outbound Message Type

•

XAI Sender (XAI)

•

External System

Inbound Communications

•

XAI Inbound Service

See Chapter 9 : Integrating Oracle Utilities Smart Grid Gateway with Other Systems for more information about creating these components when configuring communications with head-end systems and middleware.

Smart Grid Gateway Adapters

This chapter describes the components provided with Oracle Utilities Smart Grid Gateway adapters. This includes:

•

Smart Grid Gateway Adapter Overview

•

Oracle Service Bus Projects

•

Adapter-Specific Business Objects

•

Oracle Business Process Execution Language Composites

Adapter-specific configuration guides provide additional details for each of the productized adapters.

Smart Grid Gateway Adapter Overview

This section provides a high-level overview of the components provided with Smart Grid Gateway adapters, including:

•

Oracle Service Bus Projects

•

Oracle Utilities Service and Measurement Data Foundation

•

Adapter-Specific Business Objects

•

Oracle Business Process Execution Language Composites

•

Available Smart Grid Gateway Adapters

Oracle Service Bus Projects

Smart Grid Gateway adapters use Oracle Service Bus (OSB) to provide import/upload functionality for usage readings and device events. Adapters include both base package and customizable projects, to allow implementations to customize their OSB implementation as needed to meet specific requirements.

See Oracle Service Bus Projects for more information about OSB projects used by Smart Grid Gateway adapters.

Oracle Utilities Service and Measurement Data Foundation

Smart Grid Gateway adapters are installed along with the Oracle Utilities Service and Measurement Data Foundation (D1), which contains business objects and other configurations used by all adapters. For example, business objects for each of the smart meter commands supported by Smart Gird Gateway are defined in the Meter Data Framework. These business objects create vendor-specific communications based on configuration of the head-end system service provider.

The components in the Service and Measurement Data Foundation used by Smart Grid Gateway are described in the previous chapters of this book.

Adapter-Specific Business Objects

Smart Grid Gateway adapters include adapter-specific business objects for the specific outbound and inbound communications used to execute and respond to smart meter commands. Adapters also make use of extendable lookup business objects to allow implementations to define values for different types of data (data mapping, etc.).

See Adapter-Specific Business Objects for more information about business objects used by Smart Grid Gateway adapters.

Oracle Business Process Execution Language Composites

Smart Grid Gateway adapters use Oracle Business Process Execution Language (BPEL) composites to send and receive messages between Smart Grid Gateway and vendor-specific head-end systems. This communication process includes transforming messages from the Smart Grid Gateway for to the vendor’s format (and the reverse when receiving messages).

See Oracle Business Process Execution Language Composites for more information about BPEL composites used by Smart Grid Gateway adapters.

Available Smart Grid Gateway Adapters

The vendor-based adapters available for Smart Grid Gateway include the following:

•

Adapter for Landis+Gyr (D3)

•

Adapter for Echelon (D4)

•

MV-90 Adapter for Itron (D5)

•

Adapter for Sensus (D6)

•

Adapter for Silver Springs Network (D7)

•

Adapter Development Kit (DG)

•

Adapter for Itron OpenWay (D8)

Oracle Service Bus Projects

Oracle Utilities Smart Grid Gateway adapters use Oracle Service Bus (OSB) projects to provide upload functionality for usage and device events. This section outlines the types of OSB projects provided with Smart Grid Gateway adapters, and describes the components of each type of OSB project. This includes:

•

Understanding the Upload Process

•

Adapter OSB Projects

•

Usage Upload - BASE

•

Usage Upload - CM

•

Event Upload - BASE

•

Event Upload - CM

•

Working with Adapter OSB Projects

Note : This document describes the components of the OSB projects in terms of how they are used by Smart Grid Gateway adapters. Refer to Oracle Service Bus documentation for more information about OSB projects and the types of components provided in the projects described here.

Understanding the Upload Process

This section provides a high-level description of the upload process used for both usage and device events., including:

•

Upload Process

•

OSB’s Roles in the Upload Process

Upload Process

When usage and/or device events are sent to a Smart Grid Gateway adapter, the following takes place:

1.

The head-end system sends a payload to the adapter.

2.

Oracle Service Bus (OSB) receives payload from the head-end system:

•

Parses payload into individual usage readings / device events

•

Transforms individual readers/events into standard (unified) format

•

Invokes seeder for each record

•

Creates upload statistics for each payload

3.

The OUAF receives the incoming usage reading and:

•

Determines the device and measuring component for the reading or device event.

•

Maps UOM codes in usage reading to standard UOM codes (readings only)

•

Creates an initial measurement or device event

4.

The Service Provider’s processing methods define rules for

•

Determining the type of initial measurement or device event to create

•

Mapping vendor-specific UOM codes to standard UOM codes (readings only)

•

Mapping vendor-specific status codes to standard status codes (readings only)

OSB’s Roles in the Upload Process

This section provides more details regarding the processing performed by OSB when receiving payloads from head-end systems. This includes the following:

•

JCA Adapters monitor a file system for incoming file-based payloads. The polling directory monitored by OSB can be configured based on an implementation’s requirements.

•

Java objects configured with the OSB projects perform parsing of payloads into individual usage readings or device events.

•

Xquery or XSLT scripts are used to perform transformation from head-end system format into a unified format used by all Smart Grid Gateway adapters.

•

OSB delivers individual usage or event transactions to JMS queues for processing by SGG adapters.

•

OSB creates upload statistics activities for each payload processed. See Upload Statistics for more information about upload statistics activities.

The specific components of each OSB project used to perform the above are outlined in more details in later sections.

Understanding the Upload Process

This section provides a high-level description of the upload process used for both usage and device events., including:

•

Upload Process

•

OSB’s Roles in the Upload Process

Upload Process

When usage and/or device events are sent to a Smart Grid Gateway adapter, the following takes place:

1.

The head-end system sends a payload to the adapter.

2.

Oracle Service Bus (OSB) receives payload from the head-end system:

•

Parses payload into individual usage readings / device events

•

Transforms individual readers/events into standard (unified) format

•

Invokes seeder for each record

•

Creates upload statistics for each payload

3.

The OUAF receives the incoming usage reading and:

•

Determines the device and measuring component for the reading or device event.

•

Maps UOM codes in usage reading to standard UOM codes (readings only)

•

Creates an initial measurement or device event

4.

The Service Provider’s processing methods define rules for

•

Determining the type of initial measurement or device event to create

•

Mapping vendor-specific UOM codes to standard UOM codes (readings only)

•

Mapping vendor-specific status codes to standard status codes (readings only)

OSB’s Roles in the Upload Process

This section provides more details regarding the processing performed by OSB when receiving payloads from head-end systems. This includes the following:

•

JCA Adapters monitor a file system for incoming file-based payloads. The polling directory monitored by OSB can be configured based on an implementation’s requirements.

•

Java objects configured with the OSB projects perform parsing of payloads into individual usage readings or device events.

•

Xquery or XSLT scripts are used to perform transformation from head-end system format into a unified format used by all Smart Grid Gateway adapters.

•

OSB delivers individual usage or event transactions to JMS queues for processing by SGG adapters.

•

OSB creates upload statistics activities for each payload processed. See Upload Statistics for more information about upload statistics activities.

The specific components of each OSB project used to perform the above are outlined in more details in later sections.

Understanding the Upload Process

This section provides a high-level description of the upload process used for both usage and device events., including:

•

Upload Process

•

OSB’s Roles in the Upload Process

Upload Process

When usage and/or device events are sent to a Smart Grid Gateway adapter, the following takes place:

1.

The head-end system sends a payload to the adapter.

2.

Oracle Service Bus (OSB) receives payload from the head-end system:

•

Parses payload into individual usage readings / device events

•

Transforms individual readers/events into standard (unified) format

•

Invokes seeder for each record

•

Creates upload statistics for each payload

3.

The OUAF receives the incoming usage reading and:

•

Determines the device and measuring component for the reading or device event.

•

Maps UOM codes in usage reading to standard UOM codes (readings only)

•

Creates an initial measurement or device event

4.

The Service Provider’s processing methods define rules for

•

Determining the type of initial measurement or device event to create

•

Mapping vendor-specific UOM codes to standard UOM codes (readings only)

•

Mapping vendor-specific status codes to standard status codes (readings only)

OSB’s Roles in the Upload Process

This section provides more details regarding the processing performed by OSB when receiving payloads from head-end systems. This includes the following:

•

JCA Adapters monitor a file system for incoming file-based payloads. The polling directory monitored by OSB can be configured based on an implementation’s requirements.

•

Java objects configured with the OSB projects perform parsing of payloads into individual usage readings or device events.

•

Xquery or XSLT scripts are used to perform transformation from head-end system format into a unified format used by all Smart Grid Gateway adapters.

•

OSB delivers individual usage or event transactions to JMS queues for processing by SGG adapters.

•

OSB creates upload statistics activities for each payload processed. See Upload Statistics for more information about upload statistics activities.

The specific components of each OSB project used to perform the above are outlined in more details in later sections.

Adapter OSB Projects

Smart Grid Gateways include OSB projects based on the upload functionality supported by each adapter. This section provides an overview of the objects used for usage and device event upload.

Usage Upload OSB Projects

Each Smart Grid Gateway adapter provides two OSB projects to support usage upload:

•

SGG-Dn-USAGE-BASE

•

SGG-Dn-USAGE-CM

Note : The "Dn" in the project names designates the specific adapter. For example, "D3" designates the Landis+Gyr adapter, "D6" designates the Sensus adapter, "DG" designates the Adapter Development Kit, etc.

SGG-Dn-USAGE-BASE : Contains base usage upload functionality for transforming incoming vendor-specific usage readings into the standard "unified" format used by Smart Grid Gateway adapters. This project CANNOT be modified by an implementation.

SGG-Dn-USAGE-CM : Contains extendable functionality used when transforming vendor-specific usage readings into the standard "unified" format used by Smart Grid Gateway adapters. This project can be modified to support customizations required by an implementation.

This project also contains variables that an implementation would need to modify. This includes polling directories, JMS queue information, etc.

The "SGG-Dn-USAGE-BASE" project reference services in the "SGG-Dn-USAGE-CM" project It is the "SGG-Dn-USAGE-CM" project that sends data and notifications to Smart Grid Gateway adapters.

Device Event Upload OSB Projects

Each Smart Grid Gateway adapter that supports device event upload provides the following two OSB projects:

•

SGG-Dn-EVENT-BASE

•

SGG-Dn-EVENT-CM

Note : The "Dn" in the project names designates the specific adapter. For example, "D3" designates the Landis+Gyr adapter, "D6" designates the Sensus adapter, "DG" designates the Adapter Development Kit, etc.

SGG-Dn-EVENT-BASE : Contains base device event upload functionality for transforming incoming vendor-specific device events into the standard "unified" format used by Smart Grid Gateway adapters. This project CANNOT be modified by an implementation.

SGG-Dn-EVENT-CM : Contains extendable functionality used when transforming vendor-specific device events into the standard "unified" format used by Smart Grid Gateway adapters. This project can be modified to support customizations required by an implementation.

The "SGG-Dn-EVENT-BASE" projects reference services in the "SGG-Dn-EVENT-CM" projects It is the "SGG-Dn-EVENT-CM" project that sends data and notifications to Smart Grid Gateway adapters.

Adapter OSB Projects

Smart Grid Gateways include OSB projects based on the upload functionality supported by each adapter. This section provides an overview of the objects used for usage and device event upload.

Usage Upload OSB Projects

Each Smart Grid Gateway adapter provides two OSB projects to support usage upload:

•

SGG-Dn-USAGE-BASE

•

SGG-Dn-USAGE-CM

Note : The "Dn" in the project names designates the specific adapter. For example, "D3" designates the Landis+Gyr adapter, "D6" designates the Sensus adapter, "DG" designates the Adapter Development Kit, etc.

SGG-Dn-USAGE-BASE : Contains base usage upload functionality for transforming incoming vendor-specific usage readings into the standard "unified" format used by Smart Grid Gateway adapters. This project CANNOT be modified by an implementation.

SGG-Dn-USAGE-CM : Contains extendable functionality used when transforming vendor-specific usage readings into the standard "unified" format used by Smart Grid Gateway adapters. This project can be modified to support customizations required by an implementation.

This project also contains variables that an implementation would need to modify. This includes polling directories, JMS queue information, etc.

The "SGG-Dn-USAGE-BASE" project reference services in the "SGG-Dn-USAGE-CM" project It is the "SGG-Dn-USAGE-CM" project that sends data and notifications to Smart Grid Gateway adapters.

Device Event Upload OSB Projects

Each Smart Grid Gateway adapter that supports device event upload provides the following two OSB projects:

•

SGG-Dn-EVENT-BASE

•

SGG-Dn-EVENT-CM

Note : The "Dn" in the project names designates the specific adapter. For example, "D3" designates the Landis+Gyr adapter, "D6" designates the Sensus adapter, "DG" designates the Adapter Development Kit, etc.

SGG-Dn-EVENT-BASE : Contains base device event upload functionality for transforming incoming vendor-specific device events into the standard "unified" format used by Smart Grid Gateway adapters. This project CANNOT be modified by an implementation.

SGG-Dn-EVENT-CM : Contains extendable functionality used when transforming vendor-specific device events into the standard "unified" format used by Smart Grid Gateway adapters. This project can be modified to support customizations required by an implementation.

The "SGG-Dn-EVENT-BASE" projects reference services in the "SGG-Dn-EVENT-CM" projects It is the "SGG-Dn-EVENT-CM" project that sends data and notifications to Smart Grid Gateway adapters.

Adapter OSB Projects

Smart Grid Gateways include OSB projects based on the upload functionality supported by each adapter. This section provides an overview of the objects used for usage and device event upload.

Usage Upload OSB Projects

Each Smart Grid Gateway adapter provides two OSB projects to support usage upload:

•

SGG-Dn-USAGE-BASE

•

SGG-Dn-USAGE-CM

Note : The "Dn" in the project names designates the specific adapter. For example, "D3" designates the Landis+Gyr adapter, "D6" designates the Sensus adapter, "DG" designates the Adapter Development Kit, etc.

SGG-Dn-USAGE-BASE : Contains base usage upload functionality for transforming incoming vendor-specific usage readings into the standard "unified" format used by Smart Grid Gateway adapters. This project CANNOT be modified by an implementation.

SGG-Dn-USAGE-CM : Contains extendable functionality used when transforming vendor-specific usage readings into the standard "unified" format used by Smart Grid Gateway adapters. This project can be modified to support customizations required by an implementation.

This project also contains variables that an implementation would need to modify. This includes polling directories, JMS queue information, etc.

The "SGG-Dn-USAGE-BASE" project reference services in the "SGG-Dn-USAGE-CM" project It is the "SGG-Dn-USAGE-CM" project that sends data and notifications to Smart Grid Gateway adapters.

Device Event Upload OSB Projects

Each Smart Grid Gateway adapter that supports device event upload provides the following two OSB projects:

•

SGG-Dn-EVENT-BASE

•

SGG-Dn-EVENT-CM

Note : The "Dn" in the project names designates the specific adapter. For example, "D3" designates the Landis+Gyr adapter, "D6" designates the Sensus adapter, "DG" designates the Adapter Development Kit, etc.

SGG-Dn-EVENT-BASE : Contains base device event upload functionality for transforming incoming vendor-specific device events into the standard "unified" format used by Smart Grid Gateway adapters. This project CANNOT be modified by an implementation.

SGG-Dn-EVENT-CM : Contains extendable functionality used when transforming vendor-specific device events into the standard "unified" format used by Smart Grid Gateway adapters. This project can be modified to support customizations required by an implementation.

The "SGG-Dn-EVENT-BASE" projects reference services in the "SGG-Dn-EVENT-CM" projects It is the "SGG-Dn-EVENT-CM" project that sends data and notifications to Smart Grid Gateway adapters.

Usage Upload - BASE

This section outlines the components of "SGG-Dn-USAGE-BASE" OSB projects.

"SGG-Dn-USAGE-BASE" projects define the following:

•

JAR files

•

JCA Bindings

•

Proxy Services

•

XML Schemas (IMD format, vendor format, notification format)

•

XQueries (used to transform incoming format to "unified" format)

JAR Files

JAR files contain Java objects used by the OSB project to transform and parse payloads.

JCA Bindings

JCA binding resources are used to consume JCA resources when communicating with external systems via OSB. JCA bindings can generate proxy and business services that utilities OB JCA transport to communicate with external systems through JCA adapters.

A JCA file and WSDL are required to create a JCA Transport-based proxy in Oracle Service Bus. These objects are created and delivered with each productized adapter. More information on the JCA File Adapter properties file can be found in the Oracle Fusion Middleware User's Guide for Technology Adapters.

The WSDL contained within the JCA Bindings resource is used to describe the JCA File adapter service used for each productized adapter.

Proxy Services

OSB uses proxy services to route messages between business services (such as enterprise Web services and databases) and service clients (such as external applications or other business services).

Typically two proxy services are delivered with each adapter:

•

ProcessingProxyService : The ProcessingProxyService is a local transport based proxy service. It contains the message flow where the vendor-specific validation and transformation functionalities are implemented. The publishing of processing notifications is implemented in ProcessingproxyService as well.

•

ResultsProcessingProxyService : The ResultProcessingProxyService contains actions where post-transformation logic will be implemented. Also, it will have an Error Handler responsible only for catching errors occurred after a "Plain" XML is transformed to the result transaction.

XML Schemas

All Smart Grid Gateway adapters include XML schemas that are used to verify the translations from vendor-specific formats to the unified IMD XML format. "SGG-Dn-USAGE-BASE" OSB projects typically contain the following types of XML schemas:

•

InitialLoadIMD Schema: The InitialLoadIMD schema defines the structure of the measurement data sent from OSB to the OUAF-based components of Smart Grid Gateway.

•

Vendor-specific Schema : Vendor-specific schemas define the format of the usage data being received from the head-end system. For example, the "LG-Usage-Common" schema defines the format of the usage data being received from the Landis+Gyr head-end system.

•

ProcessNotifications Schema : Smart Grid Gateway adapters also provide the XML schema that defines the XML used during all notification processing. Notification processing is what drives the creation of upload statistics activities.

XQueries

Smart Grid Gateway adapters leverage Xquery to transform the vendor formatted usage data.

Usage Upload - BASE

This section outlines the components of "SGG-Dn-USAGE-BASE" OSB projects.

"SGG-Dn-USAGE-BASE" projects define the following:

•

JAR files

•

JCA Bindings

•

Proxy Services

•

XML Schemas (IMD format, vendor format, notification format)

•

XQueries (used to transform incoming format to "unified" format)

JAR Files

JAR files contain Java objects used by the OSB project to transform and parse payloads.

JCA Bindings

JCA binding resources are used to consume JCA resources when communicating with external systems via OSB. JCA bindings can generate proxy and business services that utilities OB JCA transport to communicate with external systems through JCA adapters.

A JCA file and WSDL are required to create a JCA Transport-based proxy in Oracle Service Bus. These objects are created and delivered with each productized adapter. More information on the JCA File Adapter properties file can be found in the Oracle Fusion Middleware User's Guide for Technology Adapters.

The WSDL contained within the JCA Bindings resource is used to describe the JCA File adapter service used for each productized adapter.

Proxy Services

OSB uses proxy services to route messages between business services (such as enterprise Web services and databases) and service clients (such as external applications or other business services).

Typically two proxy services are delivered with each adapter:

•

ProcessingProxyService : The ProcessingProxyService is a local transport based proxy service. It contains the message flow where the vendor-specific validation and transformation functionalities are implemented. The publishing of processing notifications is implemented in ProcessingproxyService as well.

•

ResultsProcessingProxyService : The ResultProcessingProxyService contains actions where post-transformation logic will be implemented. Also, it will have an Error Handler responsible only for catching errors occurred after a "Plain" XML is transformed to the result transaction.

XML Schemas

All Smart Grid Gateway adapters include XML schemas that are used to verify the translations from vendor-specific formats to the unified IMD XML format. "SGG-Dn-USAGE-BASE" OSB projects typically contain the following types of XML schemas:

•

InitialLoadIMD Schema: The InitialLoadIMD schema defines the structure of the measurement data sent from OSB to the OUAF-based components of Smart Grid Gateway.

•

Vendor-specific Schema : Vendor-specific schemas define the format of the usage data being received from the head-end system. For example, the "LG-Usage-Common" schema defines the format of the usage data being received from the Landis+Gyr head-end system.

•

ProcessNotifications Schema : Smart Grid Gateway adapters also provide the XML schema that defines the XML used during all notification processing. Notification processing is what drives the creation of upload statistics activities.

XQueries

Smart Grid Gateway adapters leverage Xquery to transform the vendor formatted usage data.

Usage Upload - BASE

This section outlines the components of "SGG-Dn-USAGE-BASE" OSB projects.

"SGG-Dn-USAGE-BASE" projects define the following:

•

JAR files

•

JCA Bindings

•

Proxy Services

•

XML Schemas (IMD format, vendor format, notification format)

•

XQueries (used to transform incoming format to "unified" format)

JAR Files

JAR files contain Java objects used by the OSB project to transform and parse payloads.

JCA Bindings

JCA binding resources are used to consume JCA resources when communicating with external systems via OSB. JCA bindings can generate proxy and business services that utilities OB JCA transport to communicate with external systems through JCA adapters.

A JCA file and WSDL are required to create a JCA Transport-based proxy in Oracle Service Bus. These objects are created and delivered with each productized adapter. More information on the JCA File Adapter properties file can be found in the Oracle Fusion Middleware User's Guide for Technology Adapters.

The WSDL contained within the JCA Bindings resource is used to describe the JCA File adapter service used for each productized adapter.

Proxy Services

OSB uses proxy services to route messages between business services (such as enterprise Web services and databases) and service clients (such as external applications or other business services).

Typically two proxy services are delivered with each adapter:

•

ProcessingProxyService : The ProcessingProxyService is a local transport based proxy service. It contains the message flow where the vendor-specific validation and transformation functionalities are implemented. The publishing of processing notifications is implemented in ProcessingproxyService as well.

•

ResultsProcessingProxyService : The ResultProcessingProxyService contains actions where post-transformation logic will be implemented. Also, it will have an Error Handler responsible only for catching errors occurred after a "Plain" XML is transformed to the result transaction.

XML Schemas

All Smart Grid Gateway adapters include XML schemas that are used to verify the translations from vendor-specific formats to the unified IMD XML format. "SGG-Dn-USAGE-BASE" OSB projects typically contain the following types of XML schemas:

•

InitialLoadIMD Schema: The InitialLoadIMD schema defines the structure of the measurement data sent from OSB to the OUAF-based components of Smart Grid Gateway.

•

Vendor-specific Schema : Vendor-specific schemas define the format of the usage data being received from the head-end system. For example, the "LG-Usage-Common" schema defines the format of the usage data being received from the Landis+Gyr head-end system.

•

ProcessNotifications Schema : Smart Grid Gateway adapters also provide the XML schema that defines the XML used during all notification processing. Notification processing is what drives the creation of upload statistics activities.

XQueries

Smart Grid Gateway adapters leverage Xquery to transform the vendor formatted usage data.

Usage Upload - BASE

This section outlines the components of "SGG-Dn-USAGE-BASE" OSB projects.

"SGG-Dn-USAGE-BASE" projects define the following:

•

JAR files

•

JCA Bindings

•

Proxy Services

•

XML Schemas (IMD format, vendor format, notification format)

•

XQueries (used to transform incoming format to "unified" format)

JAR Files

JAR files contain Java objects used by the OSB project to transform and parse payloads.

JCA Bindings

JCA binding resources are used to consume JCA resources when communicating with external systems via OSB. JCA bindings can generate proxy and business services that utilities OB JCA transport to communicate with external systems through JCA adapters.

A JCA file and WSDL are required to create a JCA Transport-based proxy in Oracle Service Bus. These objects are created and delivered with each productized adapter. More information on the JCA File Adapter properties file can be found in the Oracle Fusion Middleware User's Guide for Technology Adapters.

The WSDL contained within the JCA Bindings resource is used to describe the JCA File adapter service used for each productized adapter.

Proxy Services

OSB uses proxy services to route messages between business services (such as enterprise Web services and databases) and service clients (such as external applications or other business services).

Typically two proxy services are delivered with each adapter:

•

ProcessingProxyService : The ProcessingProxyService is a local transport based proxy service. It contains the message flow where the vendor-specific validation and transformation functionalities are implemented. The publishing of processing notifications is implemented in ProcessingproxyService as well.

•

ResultsProcessingProxyService : The ResultProcessingProxyService contains actions where post-transformation logic will be implemented. Also, it will have an Error Handler responsible only for catching errors occurred after a "Plain" XML is transformed to the result transaction.

XML Schemas

All Smart Grid Gateway adapters include XML schemas that are used to verify the translations from vendor-specific formats to the unified IMD XML format. "SGG-Dn-USAGE-BASE" OSB projects typically contain the following types of XML schemas:

•

InitialLoadIMD Schema: The InitialLoadIMD schema defines the structure of the measurement data sent from OSB to the OUAF-based components of Smart Grid Gateway.

•

Vendor-specific Schema : Vendor-specific schemas define the format of the usage data being received from the head-end system. For example, the "LG-Usage-Common" schema defines the format of the usage data being received from the Landis+Gyr head-end system.

•

ProcessNotifications Schema : Smart Grid Gateway adapters also provide the XML schema that defines the XML used during all notification processing. Notification processing is what drives the creation of upload statistics activities.

XQueries

Smart Grid Gateway adapters leverage Xquery to transform the vendor formatted usage data.

Usage Upload - BASE

This section outlines the components of "SGG-Dn-USAGE-BASE" OSB projects.

"SGG-Dn-USAGE-BASE" projects define the following:

•

JAR files

•

JCA Bindings

•

Proxy Services

•

XML Schemas (IMD format, vendor format, notification format)

•

XQueries (used to transform incoming format to "unified" format)

JAR Files

JAR files contain Java objects used by the OSB project to transform and parse payloads.

JCA Bindings

JCA binding resources are used to consume JCA resources when communicating with external systems via OSB. JCA bindings can generate proxy and business services that utilities OB JCA transport to communicate with external systems through JCA adapters.

A JCA file and WSDL are required to create a JCA Transport-based proxy in Oracle Service Bus. These objects are created and delivered with each productized adapter. More information on the JCA File Adapter properties file can be found in the Oracle Fusion Middleware User's Guide for Technology Adapters.

The WSDL contained within the JCA Bindings resource is used to describe the JCA File adapter service used for each productized adapter.

Proxy Services

OSB uses proxy services to route messages between business services (such as enterprise Web services and databases) and service clients (such as external applications or other business services).

Typically two proxy services are delivered with each adapter:

•

ProcessingProxyService : The ProcessingProxyService is a local transport based proxy service. It contains the message flow where the vendor-specific validation and transformation functionalities are implemented. The publishing of processing notifications is implemented in ProcessingproxyService as well.

•

ResultsProcessingProxyService : The ResultProcessingProxyService contains actions where post-transformation logic will be implemented. Also, it will have an Error Handler responsible only for catching errors occurred after a "Plain" XML is transformed to the result transaction.

XML Schemas

All Smart Grid Gateway adapters include XML schemas that are used to verify the translations from vendor-specific formats to the unified IMD XML format. "SGG-Dn-USAGE-BASE" OSB projects typically contain the following types of XML schemas:

•

InitialLoadIMD Schema: The InitialLoadIMD schema defines the structure of the measurement data sent from OSB to the OUAF-based components of Smart Grid Gateway.

•

Vendor-specific Schema : Vendor-specific schemas define the format of the usage data being received from the head-end system. For example, the "LG-Usage-Common" schema defines the format of the usage data being received from the Landis+Gyr head-end system.

•

ProcessNotifications Schema : Smart Grid Gateway adapters also provide the XML schema that defines the XML used during all notification processing. Notification processing is what drives the creation of upload statistics activities.

XQueries

Smart Grid Gateway adapters leverage Xquery to transform the vendor formatted usage data.

Usage Upload - BASE

This section outlines the components of "SGG-Dn-USAGE-BASE" OSB projects.

"SGG-Dn-USAGE-BASE" projects define the following:

•

JAR files

•

JCA Bindings

•

Proxy Services

•

XML Schemas (IMD format, vendor format, notification format)

•

XQueries (used to transform incoming format to "unified" format)

JAR Files

JAR files contain Java objects used by the OSB project to transform and parse payloads.

JCA Bindings

JCA binding resources are used to consume JCA resources when communicating with external systems via OSB. JCA bindings can generate proxy and business services that utilities OB JCA transport to communicate with external systems through JCA adapters.

A JCA file and WSDL are required to create a JCA Transport-based proxy in Oracle Service Bus. These objects are created and delivered with each productized adapter. More information on the JCA File Adapter properties file can be found in the Oracle Fusion Middleware User's Guide for Technology Adapters.

The WSDL contained within the JCA Bindings resource is used to describe the JCA File adapter service used for each productized adapter.

Proxy Services

OSB uses proxy services to route messages between business services (such as enterprise Web services and databases) and service clients (such as external applications or other business services).

Typically two proxy services are delivered with each adapter:

•

ProcessingProxyService : The ProcessingProxyService is a local transport based proxy service. It contains the message flow where the vendor-specific validation and transformation functionalities are implemented. The publishing of processing notifications is implemented in ProcessingproxyService as well.

•

ResultsProcessingProxyService : The ResultProcessingProxyService contains actions where post-transformation logic will be implemented. Also, it will have an Error Handler responsible only for catching errors occurred after a "Plain" XML is transformed to the result transaction.

XML Schemas

All Smart Grid Gateway adapters include XML schemas that are used to verify the translations from vendor-specific formats to the unified IMD XML format. "SGG-Dn-USAGE-BASE" OSB projects typically contain the following types of XML schemas:

•

InitialLoadIMD Schema: The InitialLoadIMD schema defines the structure of the measurement data sent from OSB to the OUAF-based components of Smart Grid Gateway.

•

Vendor-specific Schema : Vendor-specific schemas define the format of the usage data being received from the head-end system. For example, the "LG-Usage-Common" schema defines the format of the usage data being received from the Landis+Gyr head-end system.

•

ProcessNotifications Schema : Smart Grid Gateway adapters also provide the XML schema that defines the XML used during all notification processing. Notification processing is what drives the creation of upload statistics activities.

XQueries

Smart Grid Gateway adapters leverage Xquery to transform the vendor formatted usage data.

Usage Upload - CM

This section outlines the components of "SGG-Dn-USAGE-CM" OSB projects.

"SGG-Dn-USAGE-CM" projects define the following:

•

Business Services

•

Proxy Services (including pre-processing and post-processing proxy services)

•

Service Accounts

•

XQueries (Environment Settings)

Business Services

Business Services control how data is delivered from OSB to the OUAF components of Smart Gird Gateway. For all Smart Grid Gateway adapters, data is transferred via JMS queue. There is a business service for the usage data, and another for the notification data used for upload statistics. JMS information for each type of message is defined within the applicable business service.

Proxy Services

The "InboundProxyService" proxy service for each OSB project contains transport configuration settings. These are stored in the "SG-Dn-USAGE-CM" project so that they can be modified by an implementation.

The transport method for all Smart Grid Gateway adapters is the JCA File Adapter. The JCA Transport Configuration section of the "InboundProxyService" contains polling controls such as polling frequency, polling directory, archive directory and error directory.

In addition, the "External Reference ID" that is stored in this proxy service. This field is compared against the External Reference Id (stored on the service provider) to determine which Service Provider is to be used to process this transaction went sent to the OUAF-based components of the adapter.

Service Accounts

Service accounts provide user names and passwords that proxy services and business services use for outbound authentication or authentication to a local or remote resource, such as an FTP server or a JMS server.

XQueries

XQueries in "SGG-Dn-USAGE-CM" projects include environment settings that allow implementations to customize how usage upload processing is performed by OSB.

Typical environment settings for usage upload include the following

Environment Setting

Description

populateRawIMD

Specifies if the initial measurement data will also store the raw data as received from the AMI vendor.

callPreProcessing

Specifies if the pre-processing proxy service is called (true/false).

callPostProcessing

Specifies if the post-processing proxy service is called (true/false).

destinationRootElementInterval

Holds the name of the XAI Inbound Service for the interval IMD Seeder.

destinationRootElementScalar

Holds the name of the XAI Inbound Service for the scalar IMD Seeder. In most cases it is the same as destinationRootElementInterval.

Specific vendors have unique environment settings. Refer to individual adapter-specific configuration guides for the specific environment settings supported for each adapter.

Usage Upload - CM

This section outlines the components of "SGG-Dn-USAGE-CM" OSB projects.

"SGG-Dn-USAGE-CM" projects define the following:

•

Business Services

•

Proxy Services (including pre-processing and post-processing proxy services)

•

Service Accounts

•

XQueries (Environment Settings)

Business Services

Business Services control how data is delivered from OSB to the OUAF components of Smart Gird Gateway. For all Smart Grid Gateway adapters, data is transferred via JMS queue. There is a business service for the usage data, and another for the notification data used for upload statistics. JMS information for each type of message is defined within the applicable business service.

Proxy Services

The "InboundProxyService" proxy service for each OSB project contains transport configuration settings. These are stored in the "SG-Dn-USAGE-CM" project so that they can be modified by an implementation.

The transport method for all Smart Grid Gateway adapters is the JCA File Adapter. The JCA Transport Configuration section of the "InboundProxyService" contains polling controls such as polling frequency, polling directory, archive directory and error directory.

In addition, the "External Reference ID" that is stored in this proxy service. This field is compared against the External Reference Id (stored on the service provider) to determine which Service Provider is to be used to process this transaction went sent to the OUAF-based components of the adapter.

Service Accounts

Service accounts provide user names and passwords that proxy services and business services use for outbound authentication or authentication to a local or remote resource, such as an FTP server or a JMS server.

XQueries

XQueries in "SGG-Dn-USAGE-CM" projects include environment settings that allow implementations to customize how usage upload processing is performed by OSB.

Typical environment settings for usage upload include the following

Environment Setting

Description

populateRawIMD

Specifies if the initial measurement data will also store the raw data as received from the AMI vendor.

callPreProcessing

Specifies if the pre-processing proxy service is called (true/false).

callPostProcessing

Specifies if the post-processing proxy service is called (true/false).

destinationRootElementInterval

Holds the name of the XAI Inbound Service for the interval IMD Seeder.

destinationRootElementScalar

Holds the name of the XAI Inbound Service for the scalar IMD Seeder. In most cases it is the same as destinationRootElementInterval.

Specific vendors have unique environment settings. Refer to individual adapter-specific configuration guides for the specific environment settings supported for each adapter.

Usage Upload - CM

This section outlines the components of "SGG-Dn-USAGE-CM" OSB projects.

"SGG-Dn-USAGE-CM" projects define the following:

•

Business Services

•

Proxy Services (including pre-processing and post-processing proxy services)

•

Service Accounts

•

XQueries (Environment Settings)

Business Services

Business Services control how data is delivered from OSB to the OUAF components of Smart Gird Gateway. For all Smart Grid Gateway adapters, data is transferred via JMS queue. There is a business service for the usage data, and another for the notification data used for upload statistics. JMS information for each type of message is defined within the applicable business service.

Proxy Services

The "InboundProxyService" proxy service for each OSB project contains transport configuration settings. These are stored in the "SG-Dn-USAGE-CM" project so that they can be modified by an implementation.

The transport method for all Smart Grid Gateway adapters is the JCA File Adapter. The JCA Transport Configuration section of the "InboundProxyService" contains polling controls such as polling frequency, polling directory, archive directory and error directory.

In addition, the "External Reference ID" that is stored in this proxy service. This field is compared against the External Reference Id (stored on the service provider) to determine which Service Provider is to be used to process this transaction went sent to the OUAF-based components of the adapter.

Service Accounts

Service accounts provide user names and passwords that proxy services and business services use for outbound authentication or authentication to a local or remote resource, such as an FTP server or a JMS server.

XQueries

XQueries in "SGG-Dn-USAGE-CM" projects include environment settings that allow implementations to customize how usage upload processing is performed by OSB.

Typical environment settings for usage upload include the following

Environment Setting

Description

populateRawIMD

Specifies if the initial measurement data will also store the raw data as received from the AMI vendor.

callPreProcessing

Specifies if the pre-processing proxy service is called (true/false).

callPostProcessing

Specifies if the post-processing proxy service is called (true/false).

destinationRootElementInterval

Holds the name of the XAI Inbound Service for the interval IMD Seeder.

destinationRootElementScalar

Holds the name of the XAI Inbound Service for the scalar IMD Seeder. In most cases it is the same as destinationRootElementInterval.

Specific vendors have unique environment settings. Refer to individual adapter-specific configuration guides for the specific environment settings supported for each adapter.

Usage Upload - CM

This section outlines the components of "SGG-Dn-USAGE-CM" OSB projects.

"SGG-Dn-USAGE-CM" projects define the following:

•

Business Services

•

Proxy Services (including pre-processing and post-processing proxy services)

•

Service Accounts

•

XQueries (Environment Settings)

Business Services

Business Services control how data is delivered from OSB to the OUAF components of Smart Gird Gateway. For all Smart Grid Gateway adapters, data is transferred via JMS queue. There is a business service for the usage data, and another for the notification data used for upload statistics. JMS information for each type of message is defined within the applicable business service.

Proxy Services

The "InboundProxyService" proxy service for each OSB project contains transport configuration settings. These are stored in the "SG-Dn-USAGE-CM" project so that they can be modified by an implementation.

The transport method for all Smart Grid Gateway adapters is the JCA File Adapter. The JCA Transport Configuration section of the "InboundProxyService" contains polling controls such as polling frequency, polling directory, archive directory and error directory.

In addition, the "External Reference ID" that is stored in this proxy service. This field is compared against the External Reference Id (stored on the service provider) to determine which Service Provider is to be used to process this transaction went sent to the OUAF-based components of the adapter.

Service Accounts

Service accounts provide user names and passwords that proxy services and business services use for outbound authentication or authentication to a local or remote resource, such as an FTP server or a JMS server.

XQueries

XQueries in "SGG-Dn-USAGE-CM" projects include environment settings that allow implementations to customize how usage upload processing is performed by OSB.

Typical environment settings for usage upload include the following

Environment Setting

Description

populateRawIMD

Specifies if the initial measurement data will also store the raw data as received from the AMI vendor.

callPreProcessing

Specifies if the pre-processing proxy service is called (true/false).

callPostProcessing

Specifies if the post-processing proxy service is called (true/false).

destinationRootElementInterval

Holds the name of the XAI Inbound Service for the interval IMD Seeder.

destinationRootElementScalar

Holds the name of the XAI Inbound Service for the scalar IMD Seeder. In most cases it is the same as destinationRootElementInterval.

Specific vendors have unique environment settings. Refer to individual adapter-specific configuration guides for the specific environment settings supported for each adapter.

Usage Upload - CM

This section outlines the components of "SGG-Dn-USAGE-CM" OSB projects.

"SGG-Dn-USAGE-CM" projects define the following:

•

Business Services

•

Proxy Services (including pre-processing and post-processing proxy services)

•

Service Accounts

•

XQueries (Environment Settings)

Business Services

Business Services control how data is delivered from OSB to the OUAF components of Smart Gird Gateway. For all Smart Grid Gateway adapters, data is transferred via JMS queue. There is a business service for the usage data, and another for the notification data used for upload statistics. JMS information for each type of message is defined within the applicable business service.

Proxy Services

The "InboundProxyService" proxy service for each OSB project contains transport configuration settings. These are stored in the "SG-Dn-USAGE-CM" project so that they can be modified by an implementation.

The transport method for all Smart Grid Gateway adapters is the JCA File Adapter. The JCA Transport Configuration section of the "InboundProxyService" contains polling controls such as polling frequency, polling directory, archive directory and error directory.

In addition, the "External Reference ID" that is stored in this proxy service. This field is compared against the External Reference Id (stored on the service provider) to determine which Service Provider is to be used to process this transaction went sent to the OUAF-based components of the adapter.

Service Accounts

Service accounts provide user names and passwords that proxy services and business services use for outbound authentication or authentication to a local or remote resource, such as an FTP server or a JMS server.

XQueries

XQueries in "SGG-Dn-USAGE-CM" projects include environment settings that allow implementations to customize how usage upload processing is performed by OSB.

Typical environment settings for usage upload include the following

Environment Setting

Description

populateRawIMD

Specifies if the initial measurement data will also store the raw data as received from the AMI vendor.

callPreProcessing

Specifies if the pre-processing proxy service is called (true/false).

callPostProcessing

Specifies if the post-processing proxy service is called (true/false).

destinationRootElementInterval

Holds the name of the XAI Inbound Service for the interval IMD Seeder.

destinationRootElementScalar

Holds the name of the XAI Inbound Service for the scalar IMD Seeder. In most cases it is the same as destinationRootElementInterval.

Specific vendors have unique environment settings. Refer to individual adapter-specific configuration guides for the specific environment settings supported for each adapter.

Event Upload - BASE

This section outlines the components of "SGG-Dn-EVENT-BASE" OSB projects.

"SGG-Dn-EVENT-BASE" projects define the following:

•

JAR files

•

JCA Bindings

•

Proxy Services

•

XML Schemas (device event format, vendor format, notification format)

•

XQueries (used to transform incoming format to "unified" format)

The components of "SGG-Dn-EVENT-BASE" OSB projects are similar to those used by "SGG-Dn-USAGE-BASE" projects (described above).

XML Schemas

All Smart Grid Gateway adapters include XML schemas that are used to verify the translations from vendor-specific formats to the unified IMD XML format. "SGG-Dn-EVENT-BASE" OSB projects typically contain the following types of XML schemas:

•

DeviceEventSeeder Schema: The DeviceEventSeeder schema defines the structure of the device event data sent from OSB to the OUAF-based components of Smart Grid Gateway.

•

Vendor-specific Schema : Vendor-specific schemas define the format of the device event data being received from the head-end system. For example, the "LG-Event" schema defines the format of the device events being received from the Landis+Gyr head-end system.

•

ProcessNotifications Schema : Smart Grid Gateway adapters also provide the XML schema that defines the XML used during all notification processing. Notification processing is what drives the creation of upload statistics activities.

Event Upload - BASE

This section outlines the components of "SGG-Dn-EVENT-BASE" OSB projects.

"SGG-Dn-EVENT-BASE" projects define the following:

•

JAR files

•

JCA Bindings

•

Proxy Services

•

XML Schemas (device event format, vendor format, notification format)

•

XQueries (used to transform incoming format to "unified" format)

The components of "SGG-Dn-EVENT-BASE" OSB projects are similar to those used by "SGG-Dn-USAGE-BASE" projects (described above).

XML Schemas

All Smart Grid Gateway adapters include XML schemas that are used to verify the translations from vendor-specific formats to the unified IMD XML format. "SGG-Dn-EVENT-BASE" OSB projects typically contain the following types of XML schemas:

•

DeviceEventSeeder Schema: The DeviceEventSeeder schema defines the structure of the device event data sent from OSB to the OUAF-based components of Smart Grid Gateway.

•

Vendor-specific Schema : Vendor-specific schemas define the format of the device event data being received from the head-end system. For example, the "LG-Event" schema defines the format of the device events being received from the Landis+Gyr head-end system.

•

ProcessNotifications Schema : Smart Grid Gateway adapters also provide the XML schema that defines the XML used during all notification processing. Notification processing is what drives the creation of upload statistics activities.

Event Upload - CM

This section outlines the components of "SGG-Dn-EVENT-CM" OSB projects.

"SGG-Dn-EVENT-CM" projects define the following:

•

Business Services

•

Proxy Services (including pre-processing and post-processing proxy services)

•

Service Accounts

•

XQueries (Environment Settings)

The components of "SGG-Dn-EVENT-CM" OSB projects are similar to those used by "SGG-Dn-USAGE-CM" projects (described above).

XQueries

XQueries in "SGG-Dn-EVENT-CM" projects include environment settings that allow implementations to customize how device event upload processing is performed by OSB.

Typical environment settings for device upload include the following

Environment Setting

Description

populateRaw

Specifies if the device event data will also store the raw data as received from the AMI vendor.

callPreProcessing

Specifies if the pre-processing proxy service is called (true/false).

callPostProcessing

Specifies if the post-processing proxy service is called (true/false).

destinationRootElement

Holds the name of the XAI Inbound Service for the device event Seeder.

Specific vendors have unique environment settings. Refer to individual adapter-specific configuration guides for the specific environment settings supported for each adapter.

Event Upload - CM

This section outlines the components of "SGG-Dn-EVENT-CM" OSB projects.

"SGG-Dn-EVENT-CM" projects define the following:

•

Business Services

•

Proxy Services (including pre-processing and post-processing proxy services)

•

Service Accounts

•

XQueries (Environment Settings)

The components of "SGG-Dn-EVENT-CM" OSB projects are similar to those used by "SGG-Dn-USAGE-CM" projects (described above).

XQueries

XQueries in "SGG-Dn-EVENT-CM" projects include environment settings that allow implementations to customize how device event upload processing is performed by OSB.

Typical environment settings for device upload include the following

Environment Setting

Description

populateRaw

Specifies if the device event data will also store the raw data as received from the AMI vendor.

callPreProcessing

Specifies if the pre-processing proxy service is called (true/false).

callPostProcessing

Specifies if the post-processing proxy service is called (true/false).

destinationRootElement

Holds the name of the XAI Inbound Service for the device event Seeder.

Specific vendors have unique environment settings. Refer to individual adapter-specific configuration guides for the specific environment settings supported for each adapter.

Working with Adapter OSB Projects

OSB projects provided with Smart Grid Gateway adapters can be accessed using the Oracle Service Bus Console. You access the OSB console by logging on to the OSB server using Internet Explorer. This section outlines some common tasks related to working with OSB projects using the OSB console, including:

•

Connecting to the OSB Console

•

Changing the Polling Directory

•

Changing Environment Settings

Connecting to the OSB Console

The address for the OSB console is:

http:// <OSB_server>:<port>/sbconsole

where:

•

<OSB_server> is the URL for the OSB server.

•

<port> is the port in which the OSB server is installed. The default port used with Smart Grid Gateway adapters is 8001.

OSB projects are located in the Project Explorer, in the Operations menu.

Changing the Polling Directory

The steps below outline how to change the polling directory used with usage upload.

Note : You must have an open Change Session in order to make changes to an OSB project.

1.

Log in to the OSB admin console.

2.

Select the "SGG-Dn-USAGE-CM" project you wish to modify in the Project Explorer.

3.

Click Proxy Services under the "SGG-Dn-USAGE-CM" project.

4.

Select the InboundProxyService (Proxy Service).

5.

Click Edit in the Change Center.

6.

Click the Edit icon in the JCA Transport Configuration section.

7.

Click the down arrow icon in the Advanced Settings bar.

8.

Change the "PhysicalDirectory" value as appropriate (to the polling directory you wish to use).

9.

Click the Last >> button.

10.

Click Save.

The PhysicalDirectory now points to the new folder location.

11.

Click the Activate button in the Change Center.

Enter a note about the change in the Description field.

12.

Click Submit.

Changing Environment Settings

The steps below outline how to change the environment settings used with event upload.

Note : You must have an open Change Session in order to make changes to an OSB project.

1.

Log in to the OSB admin console.

2.

Select the "SGG-Dn-EVENT-CM" project you wish to modify in the Project Explorer.

3.

Click XQueries under the "SGG-Dn-USAGE-CM" project.

4.

Select the EnvironmentSettings (XQuery).

5.

Click Edit.

6.

Edit the values of the environment setting elements as appropriate.

For example, to disable storing device event data as raw data, you would change the <populateRaw> element as follows:

<populateRaw>false</populateRaw>

7.

Click Save.

Working with Adapter OSB Projects

OSB projects provided with Smart Grid Gateway adapters can be accessed using the Oracle Service Bus Console. You access the OSB console by logging on to the OSB server using Internet Explorer. This section outlines some common tasks related to working with OSB projects using the OSB console, including:

•

Connecting to the OSB Console

•

Changing the Polling Directory

•

Changing Environment Settings

Connecting to the OSB Console

The address for the OSB console is:

http:// <OSB_server>:<port>/sbconsole

where:

•

<OSB_server> is the URL for the OSB server.

•

<port> is the port in which the OSB server is installed. The default port used with Smart Grid Gateway adapters is 8001.

OSB projects are located in the Project Explorer, in the Operations menu.

Changing the Polling Directory

The steps below outline how to change the polling directory used with usage upload.

Note : You must have an open Change Session in order to make changes to an OSB project.

1.

Log in to the OSB admin console.

2.

Select the "SGG-Dn-USAGE-CM" project you wish to modify in the Project Explorer.

3.

Click Proxy Services under the "SGG-Dn-USAGE-CM" project.

4.

Select the InboundProxyService (Proxy Service).

5.

Click Edit in the Change Center.

6.

Click the Edit icon in the JCA Transport Configuration section.

7.

Click the down arrow icon in the Advanced Settings bar.

8.

Change the "PhysicalDirectory" value as appropriate (to the polling directory you wish to use).

9.

Click the Last >> button.

10.

Click Save.

The PhysicalDirectory now points to the new folder location.

11.

Click the Activate button in the Change Center.

Enter a note about the change in the Description field.

12.

Click Submit.

Changing Environment Settings

The steps below outline how to change the environment settings used with event upload.

Note : You must have an open Change Session in order to make changes to an OSB project.

1.

Log in to the OSB admin console.

2.

Select the "SGG-Dn-EVENT-CM" project you wish to modify in the Project Explorer.

3.

Click XQueries under the "SGG-Dn-USAGE-CM" project.

4.

Select the EnvironmentSettings (XQuery).

5.

Click Edit.

6.

Edit the values of the environment setting elements as appropriate.

For example, to disable storing device event data as raw data, you would change the <populateRaw> element as follows:

<populateRaw>false</populateRaw>

7.

Click Save.

Working with Adapter OSB Projects

OSB projects provided with Smart Grid Gateway adapters can be accessed using the Oracle Service Bus Console. You access the OSB console by logging on to the OSB server using Internet Explorer. This section outlines some common tasks related to working with OSB projects using the OSB console, including:

•

Connecting to the OSB Console

•

Changing the Polling Directory

•

Changing Environment Settings

Connecting to the OSB Console

The address for the OSB console is:

http:// <OSB_server>:<port>/sbconsole

where:

•

<OSB_server> is the URL for the OSB server.

•

<port> is the port in which the OSB server is installed. The default port used with Smart Grid Gateway adapters is 8001.

OSB projects are located in the Project Explorer, in the Operations menu.

Changing the Polling Directory

The steps below outline how to change the polling directory used with usage upload.

Note : You must have an open Change Session in order to make changes to an OSB project.

1.

Log in to the OSB admin console.

2.

Select the "SGG-Dn-USAGE-CM" project you wish to modify in the Project Explorer.

3.

Click Proxy Services under the "SGG-Dn-USAGE-CM" project.

4.

Select the InboundProxyService (Proxy Service).

5.

Click Edit in the Change Center.

6.

Click the Edit icon in the JCA Transport Configuration section.

7.

Click the down arrow icon in the Advanced Settings bar.

8.

Change the "PhysicalDirectory" value as appropriate (to the polling directory you wish to use).

9.

Click the Last >> button.

10.

Click Save.

The PhysicalDirectory now points to the new folder location.

11.

Click the Activate button in the Change Center.

Enter a note about the change in the Description field.

12.

Click Submit.

Changing Environment Settings

The steps below outline how to change the environment settings used with event upload.

Note : You must have an open Change Session in order to make changes to an OSB project.

1.

Log in to the OSB admin console.

2.

Select the "SGG-Dn-EVENT-CM" project you wish to modify in the Project Explorer.

3.

Click XQueries under the "SGG-Dn-USAGE-CM" project.

4.

Select the EnvironmentSettings (XQuery).

5.

Click Edit.

6.

Edit the values of the environment setting elements as appropriate.

For example, to disable storing device event data as raw data, you would change the <populateRaw> element as follows:

<populateRaw>false</populateRaw>

7.

Click Save.

Working with Adapter OSB Projects

OSB projects provided with Smart Grid Gateway adapters can be accessed using the Oracle Service Bus Console. You access the OSB console by logging on to the OSB server using Internet Explorer. This section outlines some common tasks related to working with OSB projects using the OSB console, including:

•

Connecting to the OSB Console

•

Changing the Polling Directory

•

Changing Environment Settings

Connecting to the OSB Console

The address for the OSB console is:

http:// <OSB_server>:<port>/sbconsole

where:

•

<OSB_server> is the URL for the OSB server.

•

<port> is the port in which the OSB server is installed. The default port used with Smart Grid Gateway adapters is 8001.

OSB projects are located in the Project Explorer, in the Operations menu.

Changing the Polling Directory

The steps below outline how to change the polling directory used with usage upload.

Note : You must have an open Change Session in order to make changes to an OSB project.

1.

Log in to the OSB admin console.

2.

Select the "SGG-Dn-USAGE-CM" project you wish to modify in the Project Explorer.

3.

Click Proxy Services under the "SGG-Dn-USAGE-CM" project.

4.

Select the InboundProxyService (Proxy Service).

5.

Click Edit in the Change Center.

6.

Click the Edit icon in the JCA Transport Configuration section.

7.

Click the down arrow icon in the Advanced Settings bar.

8.

Change the "PhysicalDirectory" value as appropriate (to the polling directory you wish to use).

9.

Click the Last >> button.

10.

Click Save.

The PhysicalDirectory now points to the new folder location.

11.

Click the Activate button in the Change Center.

Enter a note about the change in the Description field.

12.

Click Submit.

Changing Environment Settings

The steps below outline how to change the environment settings used with event upload.

Note : You must have an open Change Session in order to make changes to an OSB project.

1.

Log in to the OSB admin console.

2.

Select the "SGG-Dn-EVENT-CM" project you wish to modify in the Project Explorer.

3.

Click XQueries under the "SGG-Dn-USAGE-CM" project.

4.

Select the EnvironmentSettings (XQuery).

5.

Click Edit.

6.

Edit the values of the environment setting elements as appropriate.

For example, to disable storing device event data as raw data, you would change the <populateRaw> element as follows:

<populateRaw>false</populateRaw>

7.

Click Save.

Adapter-Specific Business Objects

This section outlines the types of business objects provided in Smart Grid Gateway adaptesr, including:

•

Initial Measurement Data Business Objects

•

Outbound Communications Business Objects

•

Inbound Communications Business Objects

•

Extendable Lookup Business Objects

Initial Measurement Data Business Objects

Initial measurement data business objects are used to define vendor-specific initial measurements. All adapters include initial measurement data business objects. These are typically child business objects of the base (D1-owned) initial measurement data business objects (D1-InitialLoadIMDInterval or D1-InitialLoadIMDScalar).

Example: Sensus (D6)

The Sensus adapter includes the following initial measurement data business objects:

Business Object

Description

D6-InitialLoadIMDScalar

Sensus Initial Load IMD - Scalar

D6-InitialLoadIMDInterval

Sensus Initial Load IMD - Interval

Initial Measurement Data Business Objects

Initial measurement data business objects are used to define vendor-specific initial measurements. All adapters include initial measurement data business objects. These are typically child business objects of the base (D1-owned) initial measurement data business objects (D1-InitialLoadIMDInterval or D1-InitialLoadIMDScalar).

Example: Sensus (D6)

The Sensus adapter includes the following initial measurement data business objects:

Business Object

Description

D6-InitialLoadIMDScalar

Sensus Initial Load IMD - Scalar

D6-InitialLoadIMDInterval

Sensus Initial Load IMD - Interval

Outbound Communications Business Objects

Outbound communications business objects are used to define the outbound messages sent from the Smart Grid Gateway adapters to the head-end systems when executing smart meter commands. All adapters that support two-way communications with a head-end system include outbound communications business objects. There is typically one outbound communication business object for each type of message that can be sent from the adapter to the head-end system. These are most often named based on names used by the head-end system.

Example: Silver Springs Network (D7)

The Silver Springs Network adapter includes the following outbound communications business objects:

Business Object

Description

D7-AddMeterReadJobInterval

SSN - Add Meter Read Job (Interval)

D7-AddMeterReadJobScalar

SSN - Add Meter Read Job (Scalar)

D7-AddPingJob

SSN - Add Ping Job

D7-ConnectDisconnect

SSN - Connect or Disconnect

D7-GetStatus

SSN - Get Status

D7-ReplaceDeviceAtLocForDecomm

SSN - SSN - Replace Device At Location (Decomm)

D7-ReplaceLocation

SSN - Replace Location

Outbound Communications Business Objects

Outbound communications business objects are used to define the outbound messages sent from the Smart Grid Gateway adapters to the head-end systems when executing smart meter commands. All adapters that support two-way communications with a head-end system include outbound communications business objects. There is typically one outbound communication business object for each type of message that can be sent from the adapter to the head-end system. These are most often named based on names used by the head-end system.

Example: Silver Springs Network (D7)

The Silver Springs Network adapter includes the following outbound communications business objects:

Business Object

Description

D7-AddMeterReadJobInterval

SSN - Add Meter Read Job (Interval)

D7-AddMeterReadJobScalar

SSN - Add Meter Read Job (Scalar)

D7-AddPingJob

SSN - Add Ping Job

D7-ConnectDisconnect

SSN - Connect or Disconnect

D7-GetStatus

SSN - Get Status

D7-ReplaceDeviceAtLocForDecomm

SSN - SSN - Replace Device At Location (Decomm)

D7-ReplaceLocation

SSN - Replace Location

Inbound Communications Business Objects

Inbound communications business objects are used to define the inbound messages sent from the head-end system to the Smart Grid Gateway adapters when sending responses based on smart meter commands. All adapters that support two-way communications with a head-end system include inbound communications business objects. There is typically one inbound communication business object for each type of message that can be sent from the head-end system to the adapter. These are most often named based on names used by the head-end system.

Example: Silver Springs Network (D7)

The Silver Springs Network adapter includes the following inbond communications business objects:

Business Object

Description

D7-ConnectDisconnectResp

SSN - Connect or Disconnect Response

D7-GetStatusResponse

SSN - Get Status Response

D7-MeterReadResponseInterval

SSN - Meter Read Response (Interval)

D7-MeterReadResponseScalar

SSN - Meter Read Response (Scalar)

D7-PingJobResponse

SSN - Ping Job Response

Inbound Communications Business Objects

Inbound communications business objects are used to define the inbound messages sent from the head-end system to the Smart Grid Gateway adapters when sending responses based on smart meter commands. All adapters that support two-way communications with a head-end system include inbound communications business objects. There is typically one inbound communication business object for each type of message that can be sent from the head-end system to the adapter. These are most often named based on names used by the head-end system.

Example: Silver Springs Network (D7)

The Silver Springs Network adapter includes the following inbond communications business objects:

Business Object

Description

D7-ConnectDisconnectResp

SSN - Connect or Disconnect Response

D7-GetStatusResponse

SSN - Get Status Response

D7-MeterReadResponseInterval

SSN - Meter Read Response (Interval)

D7-MeterReadResponseScalar

SSN - Meter Read Response (Scalar)

D7-PingJobResponse

SSN - Ping Job Response

Extendable Lookup Business Objects

Extendable lookup business objects are used to define lookup values for certain types of data, including mapping of vendor-specific data to standard equivalents (such as vendor-specific device event names to standard names), defining vendor-specific codes (such as status codes) and others. All adapters include extendable lookup business objects. There are three primary types of extendable lookup business objects included with Smart Grid Gateway adapters:

•

Device Event Mapping : Used to define how vendor-specific device event names are mapped to standard events names. For example, the same type of event (such as a tampering alert) can have different names in different head-end systems. Device event mapping allows the same types of events received from different head-end systems to use the same standard event name in Smart Grid Gateway., regardless of the head-end system.

Device event mapping extendable lookup business objects are typically child business objects of the base (D1-owned) device event mapping business object (D1-DeviceEventMappingLookup).

•

UOM Mapping : Used to define how vendor-specific unit of measure (UOM) codes are mapped to standard UOM codes. For example, a unit of measure (such as kWh) may have different codes (and names) in different head-end systems. UOM mapping allows the measurements of the same types of UOMs from different head-end systems to use a single standard code in Smart Grid Gateway, regardless of the head-end system.

UOM mapping can also map TOU and SQI values for head-end systems that include that information in their unit of measure codes. For example, the Itron OpenWay head-end system may send UOM codes of "kWh ON" or "kWh GEN." Both of these would be mapped to the standard UOM code of ""Kilowatt Hours." For the first UOM code, the TOU code could also be mapped to "On Peak," and for the second the SQI code could be mapped to "Generated."

UOM mapping extendable lookup business objects are typically child business objects of the base (D1-owned) device event mapping business object (D1-HeadendUOMLookup).

•

Interval Status Mapping : Used to define how vendor-specific interval data codes are mapped to standard status codes. For example, a status code (such as "missing" or "outage") may have different codes (and names) in different head-end systems. Status mapping allows the status codes of the same type from different head-end systems to use a single standard code in Smart Grid Gateway, regardless of the head-end system.

Interval status mapping extendable lookup business objects are typically child business objects of the base (D1-owned) device event mapping business object (D1-IntStsCodeToCondMapLookup).

•

Other : Other types of extendable lookup business objects are used by adapters to define data used by each adapter. For example, if inbound communications sent to a head-end system include an "action code" that impacts how that communication is processed, available "action codes" can be defined in an extendable lookup.

Example: Landis+Gyr (D3)

The Landis+Gyr adapter includes the following extendable lookup business objects

Business Object

Description

D3-DeviceEventMappingLookup

Landis+Gyr Device Event Mapping

D3-HeadendUOMLookup

andis+Gyr UOM Code to Standard UOM Mapping

D3-IntStsCodeToCondMapLookup

Landis+Gyr Interval Status Code to Condition Mapping

D3-LoadActionCodeLookup

Extendable Lookup - Load Action Code

Extendable Lookup Business Objects

Extendable lookup business objects are used to define lookup values for certain types of data, including mapping of vendor-specific data to standard equivalents (such as vendor-specific device event names to standard names), defining vendor-specific codes (such as status codes) and others. All adapters include extendable lookup business objects. There are three primary types of extendable lookup business objects included with Smart Grid Gateway adapters:

•

Device Event Mapping : Used to define how vendor-specific device event names are mapped to standard events names. For example, the same type of event (such as a tampering alert) can have different names in different head-end systems. Device event mapping allows the same types of events received from different head-end systems to use the same standard event name in Smart Grid Gateway., regardless of the head-end system.

Device event mapping extendable lookup business objects are typically child business objects of the base (D1-owned) device event mapping business object (D1-DeviceEventMappingLookup).

•

UOM Mapping : Used to define how vendor-specific unit of measure (UOM) codes are mapped to standard UOM codes. For example, a unit of measure (such as kWh) may have different codes (and names) in different head-end systems. UOM mapping allows the measurements of the same types of UOMs from different head-end systems to use a single standard code in Smart Grid Gateway, regardless of the head-end system.

UOM mapping can also map TOU and SQI values for head-end systems that include that information in their unit of measure codes. For example, the Itron OpenWay head-end system may send UOM codes of "kWh ON" or "kWh GEN." Both of these would be mapped to the standard UOM code of ""Kilowatt Hours." For the first UOM code, the TOU code could also be mapped to "On Peak," and for the second the SQI code could be mapped to "Generated."

UOM mapping extendable lookup business objects are typically child business objects of the base (D1-owned) device event mapping business object (D1-HeadendUOMLookup).

•

Interval Status Mapping : Used to define how vendor-specific interval data codes are mapped to standard status codes. For example, a status code (such as "missing" or "outage") may have different codes (and names) in different head-end systems. Status mapping allows the status codes of the same type from different head-end systems to use a single standard code in Smart Grid Gateway, regardless of the head-end system.

Interval status mapping extendable lookup business objects are typically child business objects of the base (D1-owned) device event mapping business object (D1-IntStsCodeToCondMapLookup).

•

Other : Other types of extendable lookup business objects are used by adapters to define data used by each adapter. For example, if inbound communications sent to a head-end system include an "action code" that impacts how that communication is processed, available "action codes" can be defined in an extendable lookup.

Example: Landis+Gyr (D3)

The Landis+Gyr adapter includes the following extendable lookup business objects

Business Object

Description

D3-DeviceEventMappingLookup

Landis+Gyr Device Event Mapping

D3-HeadendUOMLookup

andis+Gyr UOM Code to Standard UOM Mapping

D3-IntStsCodeToCondMapLookup

Landis+Gyr Interval Status Code to Condition Mapping

D3-LoadActionCodeLookup

Extendable Lookup - Load Action Code

Oracle Business Process Execution Language Composites

Oracle Utilities Smart Grid Gateway adapters use Oracle Business Process Execution Language (BPEL) composites to provide communications between Smart Grid Gateway and head-end and other external systems.This section outlines the types of BPEL composites provided with Smart Grid Gateway adapters, including:

•

Understanding the Communication Process

•

Adapter BPEL Composites

Note : This document describes the BPEL composites in terms of how they are used by Smart Grid Gateway adapters. Refer to Oracle Business Process Execution Language documentation for more information about BPEL composites.

Understanding the Communication Process

This section provides a high-level description of the communication process used when executing smart meter commands from a Smart Grid Gateway adapter. See Understanding the Command Communication Process for more deetails concerning how outbound communications, outbound messages, and inbound communications are created.

1.

When a smart meter command is executed for a meter, an outbound message is created and sent to the head-end system.

Note : The specific type of outbound communication and outbound message created are based on the configuration of the processing methods defined for the head-end system service provider.

2.

The message is sent (via XAI sender) to a JMS queue monitored by a BPEL process.

3.

The BPEL process picks up the message, and transforms it from the Smart Grid Gatewat format into the format used by the head-end system, and deposits the transfrormed message into a JMS queue monitored by the head-end system.

4.

The head-end system attempts to execute the command, and sends a response (based on the success or failure of the command). The response message is sent to a JMS queue monitored by a BPEL process.

5.

The BPEL process picks up the message, and transforms it from the format used by the head-end system into the format used by Smart Grid Gateway, and deposits the transfrormed message into a JMS queue associated with an XAI Inbound Service.

6.

The XAI inbound service creates an inbound communication (which in turn creates a completion event, and updates the associated outbound communication).

Adapter BPEL Composites

Each Smart Grid Gateway adapter includes a set of BPEL composites used for sending and receiving smart meter commands to and from the head-end system. In addition, BPEL composites are used in bulk command processing.

Adapters typically include composites for the following types of commands:

•

Device Status Check (meter ping)

•

Commission / Decommission

•

Remote Connect / Disconnect

•

On-Demand Read

BPEL composites perform transformations and other processing on messages sent between the Smart Grid Gateway and the head-end system.

•

When sending messages from Smart Grid Gateway to the head-end system, BPEL converts the message from the Smart Grid Gateway format into the format used by the head-end system.

•

When sending message from the head-end system to Smart Grid Gateway, BPEL converts the message from the format used by the head-end system into the format used by Smart Grid Gateway.

•

Other processing includes passing data related to a command between Smart Grid Gateway the head-end system, and updating Smart Grid Gateway (or the head-end system) as appropriate. For example, commands may have a job ID in the head-end system. In such cases, the job ID might be sent back to Smat Grid Gateway (and stored on the outbound communication) after the command has been issued, but before it has been executed. Refer to the adapter-specific configuration guides for more information about the specific processing provided by each adapter’s BPEL composites.

BPEL composites for vendor-specific adapters should NOT be modified or changed. Composites provided with the Adapter Development Kit can be modified to meet the specific requirements of an implementation. See the Oracle Utilities Smart Grid Gateway Adapter Development Kit Configuration Guide for more information.

Example: Sensus (D6)

The Sensus adapter includes the following BPEL composites:

Command

BPEL Composite

Common

Common

On Demand Read

OnDemandRead

Commission / Decommission

CommissionDecommission

Remove Connect / Disconnect

ConnectDisconnect

Meter Ping

DeviceStatusCheck

Adapter BPEL Composites

Each Smart Grid Gateway adapter includes a set of BPEL composites used for sending and receiving smart meter commands to and from the head-end system. In addition, BPEL composites are used in bulk command processing.

Adapters typically include composites for the following types of commands:

•

Device Status Check (meter ping)

•

Commission / Decommission

•

Remote Connect / Disconnect

•

On-Demand Read

BPEL composites perform transformations and other processing on messages sent between the Smart Grid Gateway and the head-end system.

•

When sending messages from Smart Grid Gateway to the head-end system, BPEL converts the message from the Smart Grid Gateway format into the format used by the head-end system.

•

When sending message from the head-end system to Smart Grid Gateway, BPEL converts the message from the format used by the head-end system into the format used by Smart Grid Gateway.

•

Other processing includes passing data related to a command between Smart Grid Gateway the head-end system, and updating Smart Grid Gateway (or the head-end system) as appropriate. For example, commands may have a job ID in the head-end system. In such cases, the job ID might be sent back to Smat Grid Gateway (and stored on the outbound communication) after the command has been issued, but before it has been executed. Refer to the adapter-specific configuration guides for more information about the specific processing provided by each adapter’s BPEL composites.

BPEL composites for vendor-specific adapters should NOT be modified or changed. Composites provided with the Adapter Development Kit can be modified to meet the specific requirements of an implementation. See the Oracle Utilities Smart Grid Gateway Adapter Development Kit Configuration Guide for more information.

Example: Sensus (D6)

The Sensus adapter includes the following BPEL composites:

Command

BPEL Composite

Common

Common

On Demand Read

OnDemandRead

Commission / Decommission

CommissionDecommission

Remove Connect / Disconnect

ConnectDisconnect

Meter Ping

DeviceStatusCheck

Glossary

This glossary provides definitions of commonly used terms.

Activity Type

Defines properties common to a specific type of activity.

Add Scalar Value To Intervals

Measurement service that uses the Apply Formula measurement service to add a scalar value to the value of a specified set of interval data.

Adjust Intervals to Supplied Value

Measurement service that uses the Apply Formula measurement service to adjust the total value of a specified set of interval data to a scalar value.

Advanced Metering Infrastructure (AMI)

Refers to systems that measure, collect and analyze energy usage, and interact with advanced devices such as electricity meters, gas meters, heat meters, and water meters, through various communication media either on request (on-demand) or on pre-defined schedules.

Apply Formula

Measurement service used to apply a formula to a specified set of interval data, either by applying a summary function against all intervals of the set, or by manipulating each individual interval in series via a formula using declared constants, or within the context of other sets of input interval data.

Apply TOU Map To Interval Measuring Component

Measurement service used to apply a TOU map to a set of intervals for a specified date/time range, thereby isolating and summarizing those intervals that occurred during a specific time of use.

Automatic Meter Reading (AMR)

The technology of automatically collecting consumption, diagnostic, and status data from water meter or energy metering devices (water, gas, electric) and transferring that data to a central database for billing, troubleshooting, and analyzing.

Axis Conversion

Measurement service used to convert interval data between units of measure (UOMs) and interval sizes (SPIs), including the conversion between peak and consumption-oriented UOMs.

Bill Determinants

Measurement data summarized for use by a billing application. Bill determinants can take the form of TOU-mapped interval consumption, scalar consumption, scalar readings, and/or interval consumption obtained via measurements. A common variety of bill determinant is TOU-mapped interval consumption, which reduces a full month's worth of interval data into several buckets of consumption based on time of use.

Command

A communication sent to a device to perform some action on the device, such as Connect, Disconnect, Commission, Decommission, On-Demand Read, or Device Status Check (Ping)

Communication

A record of a message sent between Oracle Utilities Smart Grid Gateway and an external system, such as a head-end system or edge application. Communications can flow both inbound and outbound, and can be both one-way and two-way.

Communication Component Device

Devices that are attached to other devices and provide two-way communication with a head-end system and can send readings to head-end systems and/or other data collection systems.

Communication components are used in situations in which the underlying meter is not capable or not enabled to handle this data. Devices of this sort are sometimes referred to as ERT (Electronic Receiver/Transmitter) meters, or communication modules (for example, the term "gas module" may refer to a communication module attached to a gas meter).

Completion Event

Records used to create or update transactions that reflect the effect of an activity. For example, issuing a commission device command could result in the creation or update of an install event while a read device command could result in the creation of initial measurement data.

Consumption

A measurement by a given device of the amount of energy, water, gas, etc. consumed over a given time period. Synonymous with the term "measurement".

Consumptive

Describes a measuring component for which readings are equivalent to the consumption. For example, if we receive a reading of 400 on January 15 and a reading of 600 on February 15, a consumptive measuring component's consumption between January 15 and February 15 would be 600 (not 200).

Contact

An individual or a business entity with which a company has contact. Each contact must reference a contact type.

Contact - Email

Email addresses related to a contact

Contact - Identifier

Identifiers related to a contact, such as social security number, driver's license number, or the contact's ID in a prior system.

Contact - Name

Names related to a contact

Contact - Phone

Phone numbers related to a contact

Contact Type

Defines the properties of a class of entities (businesses, persons).

Convert Scalar Consumption To Interval

Measurement service used to convert a scalar consumption value to a set of interval measurements.

Create Intervals

Measurement service used to create interval data based on supplied parameters (UOM, SPI, number of intervals, value, etc.)

Demand

The rate at which a commodity is delivered at a given instant or averaged over a designated time. For electricity, demand is often expressed in kilowatts (kW) or kilovolt-amperes (kVa).

Device

A physical or virtual object that holds one or more measuring components that can produce data to be handled by the system. Devices can include meters, substations, transformers, demand response devices, weather stations, etc.

Device Configuration

A specific configuration of a device. Over time, a device can have many configurations. Use of effective-dated device configuration allows the device to retain its identifier(s) even while the quantities it is measuring are changing.

Device Configuration Type

Defines the properties of device configurations of this type, including the valid types of measuring components that can be configured for the device.

Device Event

An event of some sort that has taken place relative to a device. Device events can include power outages, power restorations, tampering alerts, command completion, and other information

Device Status Check

A communication sent to a device to test whether the device is communicating with the network, determine the connection status of the meter, and when possible if there are any known malfunctions

Device Type

Information about a class of devices, including properties that apply to all devices of a type, but can be overridden for an individual device.

Distribution Company (DISCO)

A utility company that constructs and maintains the distribution network that delivers a commodity to customers. Depending upon the regulations within the territory, a distribution company may or may not be responsible for billing the customer.

Divide Intervals By Scalar Value

Measurement service that uses the Apply Formula measurement service to divide the values of a specified set of interval data by a scalar value.

Electronic Receiver/Transmitter (ERT)

Devices that are attached to other devices and provide two-way communication with a head-end system and can send readings to head-end systems and/or other data collection systems.

Exception Type

Defines properties common to many exceptions, including the category of the exception.

Extract Subset of Intervals

Measurement service used to extract a subset of interval data from a specified set of intervals.

Factor

A centrally stored set of values for use in validation rules, bill determinants calculations, and other processes. A factor can have different values depending upon some definable attribute of a system object, such as customer size associated with a service point. The values are effective-dated so that changes over time are retained. Examples of factors can include minimum/ maximum thresholds, loss factors, etc. Classes of factors are defined that can have numeric values (as in the above examples), or values pointing to profile measuring components or VEE groups.

Factor Value

An effective-dated value - either a number, a profile measuring component, a VEE group, or some custom-defined value - assigned to a factor and associated to the value of some attribute of a system object. For example, let's assume that a service point can be classified as residential, commercial, or industrial. The tolerance percentage by which a customer's consumption can exceed last month's consumption can be tighter as the customer's SP increases in size. An example configuration of factor values for a single factor called "tolerance percentage" could be: Residential - 20% Commercial - 10% Industrial - 5%

Final Measurement

Measurement data that has been validated, and if necessary, edited & estimated, and is ready for use in down-stream processing such as bill determinants calculations. Only one final measurement can exist for a given date/time for a given measuring component; one final measurement exists per interval, and likewise one final measurement exists for each scalar reading. In both cases, the final measurement value stored represents the amount consumed between its date/time and the prior final measurement's date/time.

Function

An online-initiated action applied to measurement data, comprising one or more measurement services.

Head-End System

A system that collects measurement data and meter events for eventual submission to the application. Many devices can communicate to the application through a single head-end system. A utility may have numerous head-end systems through which they communicate with devices.

Identify Spikes

Measurement service used to identify spikes in a specified set of interval data based on a spike percentage tolerance.

Identifiers

Names, numbers, or other values used to identify an entity within the system, including devices, measuring components, service points, etc.

Inbound Communication

Communication sent to Oracle Utilities Smart Grid Gateway from an external system, such as a head-end system or edge application

Inbound Communication

Communication sent to MDF (Service and Measurement Data Foundation) from a head-end system or other external system. Each inbound communication has an associated communication type that defines common properties of the communication.

Independent System Operator (ISO)

The entity charged with reliable operation of the grid and provision of open transmission access to all market participants on a non-discriminatory basis.

Initial Measurement Data (IMD)

A set of one or more readings or measurements that have been loaded into the application, usually in a format that is standard for MDF (Service and Measurement Data Foundation). Over its lifecycle (as pertains to MDM - Meter Data Management), any readings within the IMD are converted into consumption, which is then typically subject to VEE processing and then finalized - meaning stored as final measurements. Only initial measurements can be edited directly by end users of MDM. An IMD for a scalar measuring component will have a single measurement (along with a reading from which the measurement value is derived), while an IMD for an interval measuring component will usually contain multiple interval measurements.

Insert Intervals

Measurement service used to insert one or more intervals into a set of interval measurements.

Installation Constant

An installation constant is set to a value other than 1 as an indication that when calculating consumption, the installation requires that measurement data be multiplied by this value to get accurate results.

Installation Event

A device's installation information at a service point. The install event represents both the installation and removal of a device. It also records turning a device on or off while it is installed at a service point.

Installation On and Off History

A single installation event records each time the device is turned on and turned off while it is installed at a service point.

Interval Channel (Measuring Component)

A business object (BO) that represents channels associated to a device.

Interval Channel Type - Physical (Measuring Component Type)

A business object (BO) that maps properties of interval measuring component types for those Measuring Components that are part of physical devices.

Interval Channel Type - Scratchpad (Measuring Component Type)

A business object (BO) that maps properties relevant to stand-alone measuring components functioning as scratchpads for interval data manipulation.

Interval Data

Time-series data in which measurements are captured in pre-defined intervals (5 minutes, 15 minutes, 1 hour, etc.). A set of interval measurements for an interval measuring component composes an individual initial measurement data record.

Interval Data Services

Services used to access and manipulate interval measurements.

Interval Scratchpad (Measuring Component)

A stand-alone measuring component that provides the user with a means to manipulate measurement data without affecting existing measurements.

Interval Size

The "size" of an interval, representing the length of time between intervals. Interval size is typically measured in seconds-per-interval (SPI).

Manual Meter

A business object (BO) used to model a meter that does not accommodate two-way communications and must be read manually.

Manual Meter Installation Event

A business object (BO) that defines the lifecycle of the installation of a manual meter at a service point.

Manual Meter Type

A business object (BO) used to model properties for meters that are manually read.

Manufacturer

The company that makes devices, defined as an attribute of the device itself.

Market

The jurisdiction or regulatory environment in which a service point participates, defining the valid service providers and their roles. While each service point specifies only one market, different service points throughout the utility's service territory can be linked to different markets.

Market - Fallback Service Provider

For a given market relationship type, a fallback service provider may be defined at the market level, rather than storing the information redundantly on each service point. For example, an entire market might have only one ISO, and if the utility wants to store this information, they can identify the ISO as a fallback service provider for the market and the market relationship type of ISO.

Market - Relationship Type

The valid roles within a market (ISO, Distribution Company, Retailer, etc.) that have some business significance in the application.

Market - Valid Service Provider

The valid service providers for each market relationship type relevant for a given market. The service providers referenced on a service point must be valid for the combination of the service point's market and the market relationship type.

Market Participant

A variety of service provider; a company with a role within a given market such as a retailer or a distribution company.

Measurement

A measurement in MDM is synonymous with consumption, which implies that constants or multipliers may have been applied to its value. This term can be used in the context of an IMD or in reference to Final Measurements.

Measurement Condition

Codes that indicate the circumstances (estimated, missing, etc.) of individual measurements. Conditions are assigned to both scalar and interval measurement data both for initial measurement data and final measurements.

Measurement Cycle

The measurement cycle can serve two purposes: it can define the schedule for manual meter reading of devices at service points in that cycle, and it can also be configured to define when to create usage transactions for usage subscriptions associated to service points in the cycle.

Measurement Cycle Route

The route used to collect measurements for a given measurement cycle.

Measurement Cycle Route Sequence

The sequence in which measurements are collected along a measurement route.

Measurement Cycle Schedule

Defines the dates on which devices are scheduled to be read.

Measurement Service

Java services that can be invoked to manipulate interval and scalar measurements. Measurement services are invoked by measurement functions (available through certain zones within MDM), and are also used within processing of usage and VEE rules.

Measuring Component Summary

A zone shown on the VEE Group portal that displays a list of measuring components that reference a given VEE group.

Measuring Component

A single point for which data will be received and stored in the system. A measuring component can be associated to a physical device, which can have one or more measuring components, or it can be stand-alone, meaning that it is not associated to a physical device (for example, an aggregator or interval scratchpad).

Measuring Component Type

The definition of the most important properties of a measuring component, including what it measures, how regularly it measures it, whether it should be connected to a physical device or if it's used as a scratchpad or an aggregator, how its final measurements should be stored and how its user-defined values should be calculated, what rules govern VEE for Measuring Components of the type, as well as numerous display properties that are relevant within MDM. The measuring component type also defines sets of valid attribute values for groups of measuring components belonging to the type.

Measuring Component Types Referencing Group

A zone shown on the VEE Group portal that displays a list of Measuring Component types that reference the VEE group being viewed.

Merge Intervals

Measurement service used to merge a subset of interval data with a specified set of intervals (where overlaps occur, the subset intervals replace the original intervals).

Meter

A device used to measure a quantity of a service (electricity, gas, etc.) delivered to a service point.

Meter Read Download Activity Type

The structure and business rules applicable to downloading meter read information onto a handheld device.

Model

A specific model of a device produced by a manufacturer. Models for a single manufacturer can have diverse service types.

Multiplier

A value that may be applied to adjust the consumption values calculated for a device. Examples include meter/device multiplier, installation constant, loss factor, etc.

Multiply Intervals By Scalar Value

Measurement service that uses the Apply Formula measurement service to multiply the values of a specified set of interval data by a scalar value.

Normalized storage

Storing measurement data in a manner that allows for aggregation and reporting of data through database logic (SQL). Applies to both scalar and interval measurements.

Off-Peak Period

A time period during which the least amount of some consumable is being used. OR A period of relatively low system demand as specified by the supplier.

On-Peak Period

A time period during which the greatest quantity of some consumable is being used OR A period of relatively high system demand as specified by the supplier.

One-Way Communication

Communication from head-end system to Oracle Utilities Smart Grid Gateway that does not trigger a response. Examples of one-way communications include usage readings and device events.

Oracle Utilities Meter Data Management

Oracle Utilities application that provides functionality for handling large volumes of meter data to enable increased accuracy, flexibility, and scalability.

Oracle Utilities Smart Grid Gateway

Oracle Utilities application that provides functionality for orchestrating communication with head-end systems to support import of usage and events, and issuing of meter commands.

Outbound Communication

Communication sent from Oracle Utilities Smart Grid Gateway to a head-end system or other external system.

Peak

The maximum value for some measurable quantity recorded over a specified time period. A measuring component that measures peak quantities will record the highest value for the quantity over a period of time.

Peak Demand

The maximum rate of commodity consumption over a specific period of time.

Processing Method

Methods used to define the format or means by which a service provider receives data from the application, such as bill determinants, interval data, or meter events. Processing methods are also used to define how to create information internal to the application such as initial measurement data and usage transactions. Processing methods can also be used to define the information an external system wishes to subscribe to receive from our application. A BO or batch extract code are the typical processing methods defined for the transmission of data to a service provider.

Processing Role

Each processing method has a processing role, which defines the purpose of the processing method. Some examples of processing roles include: * Initial Measurement Creation (D1) * Device Activity Notification (D1) * Usage Transaction Notification (D2) * Usage Transaction Creation (D2)

Profiling of Scalar Data

The process of applying an interval consumption "shape" to a scalar measurement, using an existing interval measuring component. The individual interval values are adjusted such that when totaled, they equal the value of the scalar measurement.

Reader Remark

A type of device event used to capture and/or record specific events or circumstances encountered when a meter reader is manually reading scalar meters.

Reader remarks are submitted with scalar initial measurements when received from a head-end system or meter read collection system. Reader remarks are NOT uploaded along with other device events. Reader remarks are ALWAYS associated with a scalar initial measurement.

Reading

The value recorded by a measuring component at a given point in time. A reading often needs to be interpreted in the context of an earlier reading in order to derive a consumption value that would be stored as a measurement. For example, a reading of 1000 for a subtractive measuring component taken on February 1 in the context of a prior reading of 600 taken on January 15 would result in a consumption (measurement) of 400. Readings can either be consumptive or subtractive.

Register (Measuring Component)

A business object (BO) that represents a scalar register found on a standard or smart meter. It does not have a lifecycle, and should be associated with a device configuration.

Register Type - Physical (Measuring Component Type)

Measuring component type business object (BO) that enumerates the properties used by scalar registers.

Remove Intervals

Measurement service used to remove one or more intervals from a set of interval measurements.

Retail Company

A company that is authorized to buy and re-sell a commodity (such as electricity or gas) directly to customers based on territorial regulations.

Retrieve Interval Consumption

Measurement service used to retrieve one or more interval measurements.

Retrieve Scalar Consumption

Measurement service used to retrieve one or more scalar measurements.

Route Management

A portal used to maintain the sequence of service points within a Measurement Cycle Route.

Scalar Usage

A measurement of the amount of energy, water, gas, etc. consumed for a given measuring component for a given time period.

Seconds Per Interval

Seconds Per Interval, a way of expressing the length of time between which measurements are taken.

Service Investigative Order

Activities created by a service issue monitor when a specified set of events have occurred at a service point. The type of activity created by the service issue monitor is defined on the service issue monitor’s type.

Service Issue Monitor

Service tasks that analyze service points to determine if service is needed. If service is determined to be needed, the Service Issue Monitor creates a Service Investigative Order.

Service Order Requests

Requests that orchestrate the field activities (FAs) and smart meter messages (commands) necessary to change the service point and its installation, to enable or disable service, cut service for non-payment, etc.

Service Point

A location at which a company supplies service. Used to store information describing the type of service and how it is measured.

Service Point Identifier Type

Specific types of service point identifiers.

Service Point Identifier

A collection of identifiers for a given service point.

Service Point Parent

The parent of one or more service points.

Service Point Type

A specific type of service point. Defines how the application manages many aspects of the service point's behavior.

Service Provider

External entities that serve various roles relative to the application. These can be a head-end system, a billing system to which the application sends bill determinant data, a market participant in a deregulated environment, an outage management system that receives meter event data from the application, or other parties that require or provide information to the system.

Service Quantity Identifier

Further distinguishes between measured quantities that have identical UOM/TOU combinations, including situations in which the distinguishing identifier of a UOM is not accurately described as a TOU. SQIs can also be used as a stand-alone representation of a service quantity that is not measured (i.e. one that is not properly described as a UOM) within a Usage SQ collection (e.g. a billing determinant).

Service Task

Records used to capture task-related activities, including tasks performed by users of other Oracle Utilities applications, such as Oracle Utilities Customer Self Service.

Service Type

Specific types of service, such as electric, gas, steam, etc.

Set Condition

Measurement service used to set the condition (status) code of a specified set of interval data.

Shift Intervals

Measurement service used to shift one or more intervals forward or backward in time.

Smart Meter

A business object (BO) used to model smart meters of different service types.

Smart Meter Installation Event

A business object (BO) that defines the lifecycle and rules for installing a smart meter at a service point.

Smart Meter Type

A business object (BO) for device type that references a head-end system as well as a collection of head-ends that are valid for devices of the type, and indicates whether incoming data incorporates the daylight savings time shift. Additionally, the smart meter type includes a list of valid device configurations for its devices.

Substation

A subsidiary station of an electricity generation, transmission and distribution system where voltage is transformed from high to low or the reverse using transformers.

Subtract Scalar Value From Intervals

Measurement service that uses the Apply Formula measurement service to subtract a scalar value from the value of a specified set of interval data.

Subtractive

Describes a measuring component for which consecutive readings must be subtracted to derive a consumption value.

Time of Use

Time of Use - modifiers for a given unit of measure that indicate a period of time during which a quantity has been used, such as On-Peak (meaning during a time when the greatest quantity of some consumable is being used), Off-Peak (meaning during a time when the least amount of some consumable is being used), etc.

Transformer

A device that transferselectrical energyfrom onecircuitto another.

Two-Way Communication

Communication sent from Oracle Utilities Smart Grid Gateway to an external system, such as a head-end system or edge application that triggers a response. Most commands are two-way communications, where Oracle Utilities Smart Grid Gateway issues a command, and the head-end system sends a response as to the success or failure of the command.

Unit of Measure

Identifies quantities measured, such as KWH, KW, cubic feet, degrees Celsius, etc.

Upload Statistics Activities

Activities used to track processing of initial measurement data and device event upload processing.

Usage

A generic term for the amount of energy, water, gas, etc. consumed at one or more service points, sometimes representing quantities that have been adjusted from the original calculated consumption.

User-Defined Measurement Values

Additional values optionally stored with a given measurement that can be used in various calculations. For example, a customer's gas consumption might be measured in cubic feet, but needs to be sent to a billing system in therms. A user-defined value to convert consumption in cubic feet into therms can be configured, and the therm value will then be stored with the measurement in cubic feet.

Validation, Estimation, and Editing (VEE)

The process by which initial measurement data is validated, estimated (if necessary) and edited (if necessary) based on a set of user-defined rules.

VEE Eligibility Criteria

User-definable conditions that could cause a given VEE rule to be applied or skipped. This could involve the evaluation of some attribute of the device or measuring component, or something else entirely.

VEE Exception

An exception generated during Validation, Estimation and Editing (VEE) processing of initial measurement data. Exceptions are assigned a severity that is used in determining whether or not the initial measurement data should be transitioned into an exception state.

VEE Group

A collection of VEE Rules.

VEE Group Matrix (Factor)

A VEE rule within a VEE group can be configured to select from a list of VEE groups (referred to as a matrix) whose associated rules are to be executed next. This list of VEE groups is configured as the values of a factor. One example of its use could be to call geographically-specific VEE groups from within a larger-purpose group. A residential VEE group might contain a rule that will pick the VEE group to execute based on service point location, where the VEE Group Matrix specifies: SP in the North - VEE Group N SP in the East - VEE Group E SP in the South - VEE Group S.

VEE Group Matrix (Factor) Referencing Group

A zone that displays a list of VEE group matrices (factors) that reference the VEE group being viewed in the VEE group portal.

VEE Rule

Standard and custom Validation, Estimation and Editing (VEE) Rules that perform checking and/or manipulation of initial measurement data.

VEE Rules Referencing Group

A zone that displays a list of VEE rules that reference the VEE group being viewed in the VEE group portal.

Base Package Configuration Objects

This appendix provides lists of some base package configuration objects that can aid when implementing Oracle Utilities Smart Grid Gateway. This includes:

•

Base Package Data Areas

•

Base Package Extendable Lookups

Base Package Data Areas

The table below lists the available Service and Measurement Data Foundation base package data areas.

Data Area

Description

D1-ActCmdRequestTypeCommon

Command Request Type Common Data Area

D1-ActivityCommon

Activity Command Data Area

D1-ActivityTypeBasis

Common Schema of Activity Type

D1-AdminBOExceptionHandling

Admin BO Exception Handling Common

D1-AmountandCondition

Amount and Condition Data Area

D1-BOAuditChangedValues

BO Audit Changed Values

D1-BulkNotification

Bulk Notification

D1-BulkResponseMessage

Bulk Response Message

D1-CEBOExceptionHandling

Completion Event Exception Handling

D1-CISAddress

Address Data Area

D1-CancelCommand Common

Cancel Command Data Area

D1-CommTypeBasisDA

Communication Type Basis

D1-CommTypeBasisUIHintDA

Communication Type Basis

D1-CommandReqIBCommCommonDA

Common Inbound Commn for Command Request

D1-CommandReqOBCommCommonDA

Common Outbound Commn for Command Request

D1-CommandRequestCommon

Command Request Common Data Area

D1-CommandRequestTypeCommon

Command Request Type Common Data Area

D1-CommentsAndInstruction

Comments and Instructions Data Area

D1-CommonActivityType

Activity Type

D1-CommonDeviceDataDetails

Common Device Data Details

D1-CommonFactor

Common Factor

D1-CommonFactorValue

Common Factor Value

D1-CommonIMD

Common Initial Measurement Data

D1-CommonIMDAudit

Common IMD Audit

D1-CommonIMDSeeder

Common IMD Seeder

D1-CommonInstantiableBOOutput

Common Instantiable BO’s Output

D1-CommonMeasurementSvcsOutput

Common Measurement Service Output

D1-CommonMeterData

Common Meter Data

D1-CommonMeterTypeData

Common Meter Type Data

D1-CommnoProcMethodDetails

Common Processing Method Details

D1-CommonSIMType

Common Service Issue Monitor Type Data

D1-CommonSrvcProvDetails

Common Service Provider Details

D1-CommonSyncRequestContact

Common for Sync Request Contact

D1-CommonSyncRequestDC

Common for Sync Request Device Config

D1-CommonSyncRequestDvc

Common for Sync Request Device

D1-CommonSyncRequestIE

Common for Sync Request Install Event

D1-CommonSyncRequestInData

Sync Request Inbound Common Data

D1-CommonSyncRequestMC

Common for Sync Request Inbound MC

D1-CommonSyncRequestSP

Common for Sync Request Service Point

D1-CommonUomSpiIdentGroup

Common UOM/SPI Identification Group

D1-CommonVEEIMD

Common VEE Initial Measurement Data

D1-CompletionEvent

Completion Event Parent Data Area

D1-CompletionEventRetry

Completion Event With Retry Data Area

D1-ConDisconNotification

ConnectDisconnect Notification

D1-ConsumpCompScalarMCTypes

Consumption - Compatible Scalar MC Types

D1-CustomExtension

Custom Extension

D1-DeviceAndReadCEDetails

Device and Reading Completion Data

D1-DeviceCEDataDetails

Device Completion Event Data Details

D1-DeviceCEDetails

Device Completion Event Details

D1-DeviceConfigRelatedActivity

Device Config Related To Activity DA

D1-DeviceEvent

Device Event

D1-DeviceListDA

Device List

D1-DeviceRelatedActivity

Device Related to Activity Data Area

D1-DeviceStatusCheckNotif

Device Status Check Notification

D1-DuplicateIMDCheckExcep

Duplicate IMD Check Excep

D1-DuplicateIMDCheckMain

Duplicate IMD Check Main

D1-EligibleProfileFactors

Eligible Profile Factors for Data Creation

D1-EventBarProfileData

Event Bar Profile Data

D1-EventBarProfileList

Event Bar Profile List

D1-EventInformation

Event Information

D1-ExceptionInformation

Exception Information

D1-ExtendableLookupColumn

Extendable Lookup Common Data Area

D1-ExtendedMsrmtList

Extended ML

D1-ExternalActivity

External Activity

D1-ExternalActivityElement

External Activity Element

D1-ExternalApplicationCommon

External Application Common

D1-FVOverlayDefaultProfileList

Final Values Overlay Default Profile List

D1-FVOverlayProfileData

Final Values Overlay Profile Data

D1-FailReponse

Fail Response Data Area

D1-FallbackSPrValList

Fallback Service Provider Validation List

D1-FileHeaderInfoDA

Upload Statistics File Header Information

D1-FindMeasurementCriteria

Find Measurement Criteria Data Area

D1-GenSavePointDispDA

Generic Savepoint Dispatcher DA

D1-GenericCompletionEvent‘

Generic Completion Event Parent Data Area

D1-IBActionsInfoComm

Edit delete actions and rec. info

D1-IBCommCommonDA

Inbound Communication Common

D1-IERelatedActivityDataArea

Common Schema of IE Related Activities

D1-InstallEventRelatedActivity

Activity Related Installation Event

D1-MCSnapShot

SnapShot group for Sync Request Inbound MC

D1-MDDeviceStatusCheckNotifDA

Multi-Device Status Check Notification

D1-MRDownloadActivityCommon

Common schema Meter Read Dwnld Activity

D1-MeasurementDataList

Measurement Data List

D1-MultiDeviceCommandRequestDA

Multi-Device Command Request Common

D1-NumberOfIntervalsAndDateTm

Number of Intervals and Date Time

D1-OBActionsInfoComm

Edit delete actions and rec. info

D1-OBCommCommonDA

Outbound Communication Common Data Area

D1-ODMAssetNode

ODM Asset-Node

D1-ODMContactBasedSnapshot

ODM Contact Sync Request Snapshot

D1-ODMSPSnapshot

ODM SP Snapshot

D1-OutboundMessageCommon

Outbound Message Common

D1-PayloadProcessErrorsDA

Payload Errors DA

D1-PayloadProcessInfoDA

Payload Processing Information

D1-ReadDeviceNotification

Read Device Notification Data Area

D1-ReadDeviceNotification

Read Device Notification Data Area

D1-ReaderRemarkTypeCommon

Common Reader Remark Type

D1-ReadingCEDetails

Reading Completion Data

D1-ReadingDetails

Reading Data Details

D1-ReceivedResponse

Received Response Data Area

D1-RecipientList

Recipient List

D1-RequestToDoCE

Request To Do Completion Event

D1-RetryDetails

Retry Details

D1-SOAPFaultDA

SOAP Fault

D1-SOAPFaultGeneric

Generic Soap Fault Data Area

D1-SPMeterHistorySyncRequestIE

MDM SP/Meter History

D1-SPRelatedActivity

SP Related to Activity Data Area

D1-ScalToIntProfileFactor

Convert Scalar to Interval Profile Factors

D1-SSTaskAudit

Self-Service Task Audit

D1-ScratchpadMCTypes

Scratchpad MC Types

D1-StandardDeviceEventType

Standard Device Event Type

D1-SelfServiceKey

Self-Service Key

D1-SelfServiceReturnedFields

Self-Service Returned Fields

D1-SelfServiceUserFields

Self-Service User Fields

D1-SendRead

Send Read Details Data Area

D1-ServiceIssueMonitorMain

Service Issue Monitor Main

D1-ServicePointType

Service Point Type Data Area

D1-ServiceTask

Self-Service Task

D1-ServiceTaskType

Service Task Type

D1-StandardLogFields

Standard Log Fields

D1-StatusCodeDescriptions

Status Code Descriptions Data

D1-SuccessResponse

Success Response Data Area

D1-SyncRequestInbound

Inbound Sync Request

D1-TraceData

Trace Data

D1-UsageCommon

Usage Common Data Area

D1-UsageRuleElgCritCommon

Usage Rule Eligibility Criteria Cmmon

D1-VEECommon

VEE Common Data Area

D1-VEEIMDSeeder

VEE IMD Seeder Initial Measurement Data

Use the Data Area portal to view more details concerning these data areas.

Base Package Extendable Lookups

The table below lists the available meter data framework base package extendable lookups.

Business Object

Description

D1-360EventBarProfile

360 View Event Bar Profile

D1-CommLogicalStatusLookup

Communications Logical Status

D1-DaysSinceLastNormalMsrmtLkp

Days Since Last Normal Measurement

D1-DeviceErrorFlagLookup

Device Error Flag

D1-DeviceEventMappingLookup

Device Event Mapping

D1-DeviceLocationLookup

Device Location

D1-DvcCommunicationStatLookup

Device Communication Status

D1-DvcConnectionStatLookup

Device Connection Status

D1-DvcEventCategoryLookup

Device Event Category

D1-DvcFunctionalStateLookup

Device Functional State

D1-ExecutionPriorityLookup

Execution Priority

D1-ExternalActTypeIdentifier

External Activity Type Identifier

D1-ExternalCommTypeLookup

External Communication Type

D1-ExternalSystemLookup

External System Mapping

D1-FinalValuesOverlayProfile

Final Values Overlay Profile

D1-KeyLookup

Key

D1-LoadActionCodeLookup

Extendable Lookup Load Action Code Common

D1-LogicalStatusLookup

Logical Status

D1-MeasurementConditionLookup

Measurement Condition

D1-OKToEnterLookup

Ok to Enter

D1-SpecificationLookup

Asset Specification

D1-SPInstructionLookup

SP Instruction

D1-SPWarningLookup

SP Warning

D1-StdEventNameLookup

Standard Event Name

D1-TimeZoneTranslationLookup

Head-End Time Zone to Standard Mapping

D1-TransactionTypeLookup

Transaction Type

D1-YesNoLookup

Yes/No

Use the Extenable Lookup portal to view more details concerning these extendable lookups.