Common Information Model (CIM) Conformity and

Interoperability Test Procedure Development

2011 TECHNICAL REPORT

Common Information Model

(CIM) Conformity and
Interoperability Test
Procedure Development

EPRI Project Manager

J. Simmmins

3420 Hillview Avenue

Palo Alto, CA 94304-1338
USA
PO Box 10412
Palo Alto, CA 94303-0813
USA
800.313.3774
650.855.2121
askepri@epri.com
www.epri.com

1024448
Final Report, December 2011

DISCLAIMER OF WARRANTIES AND LIMITATION OF LIABILITIES

THIS DOCUMENT WAS PREPARED BY THE ORGANIZATION(S) NAMED BELOW AS AN ACCOUNT OF
WORK SPONSORED OR COSPONSORED BY THE ELECTRIC POWER RESEARCH INSTITUTE, INC. (EPRI).
NEITHER EPRI, ANY MEMBER OF EPRI, ANY COSPONSOR, THE ORGANIZATION(S) BELOW, NOR ANY
PERSON ACTING ON BEHALF OF ANY OF THEM:
(A) MAKES ANY WARRANTY OR REPRESENTATION WHATSOEVER, EXPRESS OR IMPLIED, (I) WITH
RESPECT TO THE USE OF ANY INFORMATION, APPARATUS, METHOD, PROCESS, OR SIMILAR ITEM
DISCLOSED IN THIS DOCUMENT, INCLUDING MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE, OR (II) THAT SUCH USE DOES NOT INFRINGE ON OR INTERFERE WITH PRIVATELY OWNED
RIGHTS, INCLUDING ANY PARTY'S INTELLECTUAL PROPERTY, OR (III) THAT THIS DOCUMENT IS SUITABLE
TO ANY PARTICULAR USER'S CIRCUMSTANCE; OR
(B) ASSUMES RESPONSIBILITY FOR ANY DAMAGES OR OTHER LIABILITY WHATSOEVER (INCLUDING ANY
CONSEQUENTIAL DAMAGES, EVEN IF EPRI OR ANY EPRI REPRESENTATIVE HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES) RESULTING FROM YOUR SELECTION OR USE OF THIS DOCUMENT OR
ANY INFORMATION, APPARATUS, METHOD, PROCESS, OR SIMILAR ITEM DISCLOSED IN THIS
DOCUMENT.
REFERENCE HEREIN TO ANY SPECIFIC COMMERCIAL PRODUCT, PROCESS, OR SERVICE BY ITS TRADE
NAME, TRADEMARK, MANUFACTURER, OR OTHERWISE, DOES NOT NECESSARILY CONSTITUTE OR
IMPLY ITS ENDORSEMENT, RECOMMENDATION, OR FAVORING BY EPRI.
THE FOLLOWING ORGANIZATIONS, UNDER CONTRACT TO EPRI, PREPARED THIS REPORT:
EnerNex
Boreas Group
Xtensible Solutions

NOTE
For further information about EPRI, call the EPRI Customer Assistance Center at 800.313.3774 or
e-mail askepri@epri.com.
Electric Power Research Institute, EPRI, and TOGETHERSHAPING THE FUTURE OF ELECTRICITY are
registered service marks of the Electric Power Research Institute, Inc.
Copyright 2011 Electric Power Research Institute, Inc. All rights reserved.

Acknowledgments

The following organizations, under contract to the Electric Power

Research Institute (EPRI), prepared this report:
EnerNex
620 Mabry Hood Road, Suite300
Knoxville, TN 37932
Principal Investigators
K. Stefferud
B. Muschlitz
Boreas Group
730 S. Elizabeth Street
Denver, CO 80209
Principal Investigators
R. Sarfi
W. Boswell
B. Lyons
Xtensible Solutions
6312 S. Fiddlers Green Circle, Suite 210E
Greenwood Village, CO 80111
Principal Investigator
M. Ortiz
This report describes research sponsored by EPRI.
EPRI would like to acknowledge the support of the following
organizations: American Electric Power, Consumers Energy, and
Southern California Edison.

This publication is a corporate

document that should be cited in the
literature in the following manner:
Common Information Model (CIM)
Conformity and Interoperability Test
Procedure Development.
EPRI, Palo Alto, CA: 2011.
1024448.

iii

Product
Description

Without a common language between applications in the back office,

the cost and risk of a Smart Grid implementation increases.
Operating costs following implementation also increase, as each
nonstandard interface must be modified every time one of the
applications using it is upgraded. Creation of interapplication
messaging standards using the Common Information Model (CIM)
has been hampered by the lack of conformity and interoperability test
procedures. This report summarizes a standardized method for
developing interoperability tests for International Electrotechnical
Commission (IEC) standard 61968 and for the development and
implementation of a conformity/interoperability test harness.
Background
While utilities may desire vendors to be interoperable using a
semantic standard, there has been no certifying authority to
demonstrate compliance and no open, reliable testing mechanism to
ascertain application conformance. The result has been a lack of
conformity requirements in the requests for proposals.
Objectives
One project objective is to establish an interoperability and
conformity research facility at EPRIs Knoxville facility. EPRI built a
cloud-based solution for use in basic research on interoperability
between the advanced metering infrastructure (AMI), distribution
automation, and other applications such as Meter Data Management
Systems (MDMS) and Outage Management Systems (OMS). The
goals of the EPRI cloud-based solution are to

Solidify confidence and credibility in the testing process

Reduce the cost of interoperability research

Connect physically and logically to utility, vendor, and other

servers in order to establish a virtual lab, enabling
interoperability testing with remote CIM-based systems

Increase the number of interoperability tests that can be

performed while decreasing the cost per test

Use the facility for interoperability and conformity research

protocol testing, and refinement of testing processes
v

Approach
EPRI attempted to obtain input from all organizations that have
been stakeholders in the development of IEC standard 61968, with
the goal of developing interoperability test protocols for the standard.
EPRI worked with the Open Smart Grid (OpenSG) Systems and
Conformity Working Groups as well as the National Institute of
Standards and Technology (NIST) Smart Grid Testing and
Certification Committee to 1) develop a test method, 2) formulate
draft policies, processes, procedures, and goals, 3) develop a test
harness to apply the procedures, and 4) pilot the interoperability
process and apply lessons learned. The conformity/interoperability
test harness was designed to be useful for any semantic level standard
such as Open Automated Demand Response (OpenADR), Open
Automatic Data Exchange (OpenADE), MultiSpeak (a registered
trademark of the National Rural Electric Cooperative Association),
and ZigBees Smart Energy Profile (SEP) 2.0.
Results
Five IEC 61968-9 standard tests have been developed for the
following test cases:

Scheduled Meter Read

On-Demand Meter Read

Meter Outage

Meter Tamper Detection

Remote Meter Connect/Disconnect

Applications, Value, and Use

The intended use of this report is to promote standardized interfaces
between utility back-office products. The intended audience is
utilities and vendors who want to develop interoperable utility
applications such as MDMS, OMS, and Distribution Management
Systems (DMS). This report can best be used as a standardized
method for testing interoperability between meters and the systems
that interface with them.
Keywords
Conformity
Interoperability
IEC Standard 61968
Common Information Model (CIM)
Semantic Standard
vi

Abstract
The EPRI Common Information Model (CIM) Interoperability and
Conformance Test Procedure Project designed a method for
developing, documenting, and executing standardized CIM tests
using best-practices system engineering principles. In specific, the
EPRI CIM test project developed test cases and test procedures to
verify and validate International Electrotechnical Commission (IEC)
standard 61968-9 meter reading and control messages. The method
used to develop the 61968-9 tests can be used to develop
standardized interoperability test procedures for other parts of the
CIM as well. The method can also be extended to other semantic
level standards such as Open Automated Demand Response
(OpenADR), Open Automatic Data Exchange (OpenADE),
MultiSpeak (a registered trademark of the National Rural Electric
Cooperative Association), and ZigBees Smart Energy Profile (SEP)
2.0.

vii

Executive
Summary

Interoperable systems with standardized interfaces can leverage

existing technology to more easily modify current systems and
develop future applications. For example, standardized meter
interfaces would allow a Meter Data Management System (MDMS)
to process status codes from different manufacturers using a single set
of algorithms rather than requiring custom algorithms for each
manufacturers meters. Thus standardized interfaces benefit both
utilities and application vendors. The tests described here allow
utilities and application developers to verify that their systems are in
compliance with the basic Common Information Model (CIM)
meter interfaces specified in IEC 61968 - 9.
The five meter interoperability tests specified here can be used to
verify interoperability for scheduled meter reads, for on demand
meter reads, for meter detected outages, for meter tamper detection
and for remote meter connections and disconnections.
In order to facilitate ease of testing a test harness and remote testing
capabilities have been produced by this project allowing tests to be
run anytime, from any IP-connected utility, vendor, or other
location.
In response to concerns by utilities and vendors that CIM is too
abstract to be useful, the testing methodology demonstrates a
concrete methodology to develop and test system-to-system messages
which constitute a framework for CIM implementation. Several
procedural changes are needed in order to allow the CIM to be
implemented without extensive and expensive tailoring at each utility
by each application integrator.
First, the formal IEC standard development and approval process is
lengthy and thus quite slow which prevents usable up-to-date
versions of the CIM from being available for purchase. For example
the current version of IEC 619868 - 9 is dated 2009. But
development and subsequent testing of Part 9 applications typically
require use of the latest current Part 9 version which is not yet
publically available. A method which allows both utilities and
vendors to acquire current versions of CIM specifications is required
in order to implement the CIM without expensive and time
consuming delays and modifications.

ix

Second, the concept that IEC 619868 - 9 furthers interoperability by

providing an information model usable for a single utility needs to be
expanded. IEC 619868 - 9 needs to specify interfaces which are
interoperable among multiple utilities as is the case for the CIMs
Power System Model.
Third, best practices for common information models require
definition of both the information as it is stored and the information
as it is transmitted. Thus the IEC CIM - 9 should specify data
content in terms of data item descriptions, units, precision, ranges
and limitations of data usage as well as specify specific standard
messages for data transmission. Of course, the CIM is not static and
updates will be required. Thus the CIM should specify data
definitions and messages that are both forwardly and backwardly
compatible.
Fourth and lastly, a workable definition of CIM compliant is
needed. The CIM is a large specification contained in a dozen or
more IEC specifications so it would be difficult for any given product
to be compliant with all of the CIM specifications. However, the
current practice of executing tests with a very limited and in some
cases, a single CIM message, will not produce reusable systems or
those which are easily integrated. Without a standardized method of
designing, testing, and certifying a set of CIM-compliant messages
for subsets of the CIM, the CIM cannot be used by either utilities or
vendors to advance interoperability, nor reduce the cost of
integration, nor allow vendors to leverage existing product
development.
It is the intent of this report to specify a testing methodology for a
subset of CIM - 9 messages which can be used to demonstrate
interoperability of five basic meter functions between multiple
systems produced by multiple vendors. This methodology can be
extended to include any CIM message as well as non-CIM, semantic
standards.

Table of Contents
Section 1: Introduction ............................................1-1
Section 2: Challenges, Goals and Objectives ............2-1
Section 3: Development of Test Procedures for IEC
61968 ....................................................3-1
Methodology ................................................................... 3-2
Project Participants ........................................................... 3-3
Test Tool Overview ........................................................... 3-4
Test Bed and Test Harness ................................................. 3-5
Section 4: CIM Part 9 Test Suite ...............................4-1
Scheduled Meter Read Tests .............................................. 4-2
ECITP 2.01 Scheduled Meter Read Nominal
Interoperability ........................................................... 4-2
ECITP 2.02 Scheduled Meter Read System Errors ........ 4-2
On Demand Meter Read Tests ........................................... 4-2
2.03 On Demand Meter Read Nominal
Interoperability ........................................................... 4-3
2.04 On Demand Meter Read System Errors ................. 4-3
Meter Outage Tests .......................................................... 4-4
2.05 Meter Outage Nominal Interoperability ................. 4-4
2.06 Meter Outage System Errors ................................ 4-5
Meter Tampering Detection Tests........................................ 4-5
2.07 Meter Tampering Detection Nominal
Interoperability ........................................................... 4-5
2.08 Meter Tampering Detection System Errors .............. 4-6
Meter Disconnect/Reconnect Tests ..................................... 4-6
2.09 Meter Disconnect/Reconnect Nominal
Interoperability ........................................................... 4-6
2.10 Meter Disconnect/Reconnect System Errors............ 4-7
Section 5: Recommendations ...................................5-1
Appendix A: EPRI Interoperability Test Harness
How-To-Deploy Tutorial .......................... A-1
Introduction .................................................................... A-1
xi

Getting Started ............................................................... A-1

Instance Creation Steps ................................................... A-1
Creating a new test harness instance ........................... A-2
Deploying applications to each instance .......................... A-10
SSHing Into the Server.............................................. A-11
Verify Test Harness is Functioning .............................. A-13
Appendix B:
EPRI Interoperability Test Harness
Tutorial ...................................................B-1
Introduction ..................................................................... B-1
Getting Started ................................................................ B-1
Validate Connectivity .................................................. B-1
Loading a project into soapUI ...................................... B-2
Using soapui .............................................................. B-4
Failed Message Communication Example ...................... B-6
Successful Message Communication Example .............. B-11
Incoming Messages ........................................................ B-13
Starting the CIS Mock Service .................................... B-14
Requesting the Message ............................................ B-16
Meter Connect Package .................................................. B-21
CIS ...................................................................... B-22
MDMS .................................................................... B-23
AMI ...................................................................... B-26
Meter OnDemand Package ............................................. B-28
CIS ...................................................................... B-29
MDMS .................................................................... B-31
AMI ...................................................................... B-33
Meter Scheduled Package ............................................... B-34
AMI ...................................................................... B-35
MDMS .................................................................... B-36
Meter Tamper Package ................................................... B-37
AMI ...................................................................... B-37
MDMS .................................................................... B-38
CIS ...................................................................... B-38
Meter Outage Package................................................... B-39
OMS ...................................................................... B-39
MDMS .................................................................... B-40
Port Forwarding ............................................................. B-40
Appendix C:

Creating XSD files ............................. C-1

Appendix D:

Glossary.......................................... D-1

xii

List of Figures
Figure 3-1 IEC 61968 - 9 Test Cases ....................................... 3-2
Figure 3-2 Test Artifact Development Sequence ........................ 3-3
Figure 3-3 CIM Test Team....................................................... 3-4
Figure 3-4 CIM Test Documentation Set .................................... 3-5
Figure 3-5 CIM Cloud Computing Environment ......................... 3-6
Figure 4-1 CIM Interoperability Test Development Sequence ....... 4-1
Figure A-1 EC2 Instance View................................................ A-2
Figure A-2 Request Instances Wizard, Choose An AMI ............. A-2
Figure A-3 Request Instances Wizard, Instance Details .............. A-3
Figure A-4 Request Instances Wizard, Instance Details,
Advanced ...................................................................... A-4
Figure A-5 Request Instances Wizard, Instance Details, Tags ..... A-5
Figure A-6 Request Instances Wizard, Create Key-Pair.............. A-5
Figure A-7 Request Instances Wizard, Configure Firewall.......... A-6
Figure A-8 Request Instances Wizard, Review.......................... A-7
Figure A-9 Request Instances Wizard, My Instances ................. A-7
Figure A-10 Request Instances Wizard, Vendor Naming ........... A-8
Figure A-11 My Instances, Instance Management..................... A-9
Figure A-12 Specific Instance Details, Showing Public DNS..... A-10
Figure A-13 EC2 instance, Show Master Deployment Server ... A-11
Figure A-14 Putty session, Authentication Tab ........................ A-12
Figure A-15 Putty session, Showing Deployment in Progress .... A-13
Figure A-16 Reporting UI ..................................................... A-13
Figure A-17 Browser View of Web Services .......................... A-14
Figure B-1 List of Available Web Services................................. B-2
Figure B-2 soapUI file browser ................................................ B-2
xiii

Figure B-3 SoapUI with Project in Navigator Bar ....................... B-3

Figure B-4 Meter Connect package UML diagram ..................... B-4
Figure B-5 Web UI home page ............................................... B-5
Figure B-6 SoapUI, meter service requests ................................ B-5
Figure B-7 SoapUI, modifying the endpoint url .......................... B-6
Figure B-8 SoapUI, endpoint menu .......................................... B-6
Figure B-9 SoapUI, editing the endpoint url .............................. B-7
Figure B-10 SoapUI, sending Meter Service request
message ......................................................................... B-7
Figure B-11 SoapUI failed message response ......................... B-8
Figure B-12 WebUI, home page with 0% success ..................... B-8
Figure B-13 WebUI, failed service request in package view ....... B-9
Figure B-14 WebUI failed service request log listing ............... B-9
Figure B-15 WebUI incoming log for failed request ................. B-10
Figure B-16 WebUI response message to failed message ..... B-10
Figure B-17 SoapUI successful message response ................. B-11
Figure B-18 WebUI 33% complete ..................................... B-12
Figure B-19 WebUI success for interface 1. ......................... B-12
Figure B-20 WebUI listing of log entries .............................. B-13
Figure B-21 SoapUI loading MeterConnect CIS-2 project ...... B-13
Figure B-22 SoapUI mock service start................................. B-14
Figure B-23 Mock service options .......................................... B-14
Figure B-24 SoapUI Mock service menu, start minimized ....... B-15
Figure B-25 SoapUI. Mock service, no messages ................... B-16
Figure B-26 Sending message request, changing reply
address ......................................................................... B-17
Figure B-27 SoapUI, mock services showing received
message ....................................................................... B-18
Figure B-28 SoapUI received message from mock service ...... B-19
Figure B-29 SoapUI home page showing 67% complete ....... B-19
Figure B-30 SoapUI package status showing success ............ B-20
Figure B-31 Meter Connect package, UML diagram ................ B-21
xiv

Figure B-32 Meter OnDemand package, UML diagram ........... B-28

Figure B-33 Meter Scheduled package, UML diagram ............. B-34
Figure B-34 Meter Tamper package, UML diagram ................. B-37
Figure B-35 Meter Outage package, UML diagram ................. B-39

xv

Section 1: Introduction
For almost two decades EPRI research has contributed to the development of
International Electrotechnical Commission (IEC) standards such as the
Common Information Model (CIM). The CIM provides the basis for modeldriven information exchange both within and between control centers and other
systems supporting utility operations. The development of a smarter grid depends
on the development of interoperability guidelines such as that which the CIM
provides. Having a universally accepted, well defined, model-driven information
exchange is one key component for reducing cost and risk. A description of the
CIM and its history can be found elsewhere1.
The primary challenge has been to extend CIM beyond the control center and
prove that it is stable and fully implementable. Once the CIM is extended, it is
expected to allow full data management and exchange between the transmission,
distribution, planning, and generation areas of the enterprise and with outside
entities. When new data provided by these systems can be accessed, utilities may
be able to achieve efficiencies that may lower the cost of future system upgrades
and integration.
At present there are two leading efforts for software interoperability in larger
electric utilities: the OpenSG Users Group Enterprise effort and CIM
maintained by Technical Committee 57 (TC57) of IEC. The artifacts from
these groups have been developed by different committees that have some
overlap in membership. As a result, the artifacts from the two groups cover
much of the same material, but in somewhat different manners.
Electric utilities are implementing and rolling out advanced metering
infrastructure (AMI) systems. At the present time there is no common direction
in the integration requirements of the AMI system and other key systems of the
Smart Grid, including: customer information, outage management, meter data
management, load management / demand response, distribution automation,
work management, and remote connect / disconnect systems. Most vendors have
yet to consider how to integrate emerging technologies such as in-home
controllers, home area networks, distributed energy resources, and flexible
demand response systems. Those vendors that are developing and rolling out
AMI systems are not implementing standardized interfaces thus forcing costly
custom integration between vendor products at each utility.
1

Common Information Model Primer: First Edition. EPRI, Palo Alto, CA: 2011.1024449.

1-1

Section 2: Challenges, Goals and

Objectives
Currently the CIM is being expanded beyond the control center. The expanded
CIM must be proven in term of stability, implementation and maintainability.
Once extended, the CIM is expected to allow full data management and
exchange between the transmission, distribution, planning, and generation
systems within and between utilities. When new data provided by these systems
is integrated, utilities may be able to achieve efficiencies that will lower the cost
of future system upgrades.
The primary purpose for the development of the Common Information Model
(CIM) by the companion IEC Technical Committee (TC) 57 Working Group
(WG) 13 Energy Management System API and WG 14 System Interfaces for
Distribution Management standards is to:

Reduce the cost and time required to add new electric utility applications

Protect the investment in existing electric utility applications by enabling

interoperability between native CIM and non CIM applications

Enable electric utility applications to communicate using standardized,

extensible messages, which are both forward and backwardly compatible

WG 13s IEC 61970 and WG 14s IEC 61968 series of standards are intended
to facilitate integration of various distributed software applications supporting the
operation and management of utility electrical networks. The standards specify
the interfaces that an application should implement in order to exchange
information with other applications and/or to access publicly available data in a
standard way. The application interfaces describe the content and format of the
data exchanged as well as the mechanism. For the development of new
applications, the standards enable knowing what and how information is
available for processing from other applications, as well as how the information is
expected to be transmitted and received. For the integration of an existing
application, the standards should enable a single adapter to be supplied off the
shelf for a given infrastructure Technology Platform independent of who
developed the application.
The IEC CIM standards define requirements, integration architecture, and
interfaces for the major utility applications including, but not limited to:

Energy/Distribution Management Systems

2-1

Transmission/Distribution Planning Systems

Work and Asset Management Systems

Outage Management Systems

Customer Information and Meter Data Management Systems

Geographic Information Systems

The CIM standards can be applied in any utility domain where a common model
is needed to facilitate interoperability between applications and systems
independent of any particular implementation. While not achieving full plug
and play adaptability, the CIM reduces the distance to integrate 2.
The first objective of the EPRI CIM Test Procedure project was to establish an
interoperability and conformity research facility at EPRIs Knoxville facility. The
EPRI CIM test facility is to be used for basic research on interoperability
between AMI, distribution automation, and various other applications. Goals for
the CIM test facility are to:

Solidify the confidence and credibility in the testing process

Reduce the cost of interoperability research

Connect physically (via VPN) and logically (via APIs or RPCs) to utility,
vendor, and other servers to establish a virtual lab enabling interoperability
testing with remote CIM-based systems

Increase the number of interoperability tests that can be performed

Utilize the facility for interoperability and conformity research, protocol

testing, refinement of testing processes, etc.

The first objective has been met and exceeded with a cloud based test harness
hosted by EPRI using Amazon web services. Information on using the test
harness including detailed instructions is contained in Appendices A and B of
this document. With the cloud-based EPRI solution tests can be run both at
EPRI and at any IP-enabled facility.
A second objective of the EPRI CIM Test Procedure project was to develop
interoperability test protocols for IEC 61968. EPRI worked with the OpenSG
Systems and Conformity Working Groups and the NIST Smart Grid Testing
and Certification Committee to:

Develop a standardized testing methodology

Develop draft test policies, processes, procedures, and goals

Pilot the interoperability process and apply lessons learned

The test protocols developed include a testing methodology, which can be

applied in a consistent manner for all interoperability projects regardless of who
2

Interoperability Context-Setting Framework, Gridwise Architecture Council, July, 2007

2-2

performs them. The testing methodology and lessons learned are summarized in
this final report. The test cases, test procedures, and test processes are publically
located on the OpenSG Conformity Working Group web site at
http://osgug.ucaiug.org/conformity/Shared%20Documents/CIM_TestingArtifacts
A third objective of this project is to develop a mapping between OpenSG Users
Group artifacts and the IEC 61968 standard or other CIM standards. This
interoperability mapping is intended to (i) assist utilities in specifying these
standards with confidence as requirements in their RFPs, knowing that IEC
61968-compliant AMI, ADE, and other systems could interoperate with
minimal customization, (ii) permit vendors to develop interfaces that work with
systems compatible with the standards, and (iii) enable SmartGrid solutions to be
delivered rapidly and cost-effectively to the public.
A fourth objective is to provide analysis and harmonization of the OpenSG
artifacts into an IEC TC57 submission package for CIM extensions. This effort
is also expected to include interoperability testing of the harmonization efforts.
Further, the findings and recommendations of this project concerning
interoperability best practices, processes, and procedures are expected to be
included as part of the IEC 61968 submission packages.
The OpenSG Systems and OpenSG Conformity domains have been reviewed in
detail. Common elements in the CIM were identified and gaps in both the
OpenSG domain and the CIM implementation were identified and
recommendations made to enable CIM implementation. The OpenSG domains
include:

SG Systems: OpenAMI-Enterprise

SG Systems: OpenADE / NAESB Energy Service Provider Interface

(ESPI)

SG Systems: OpenADR

SG Systems: OpenHAN

SG Conformity: ENT Conformity

Relevant CIM and OpenSG requirements were mapped to both the test cases
and to steps in the test procedures.
EPRI plans for each domain to be the focus of this and future phases of this
project. Metering, automatic data exchange and some elements of distribution
automation (i.e. automated outage detection) were the focus of the first phase.
Further phases of the project may address the OpenADR, OpenHAN, or other
domains as progress in these areas makes interoperability testing feasible and
desirable.

2-3

Section 3: Development of Test Procedures

for IEC 61968
The CIM Interoperability and Conformance Test Procedure project developed
standardized reusable test procedures and abstract test cases for interoperability
testing for the IEC 61968 - 9 standard. The test procedures are in conformance
with the NIST Testing and Certification Committee (TCC) Interoperability
Process Reference Manual (IPRM) and Certification Process Reference Manual
(CPRM). The development of said procedures was coordinated with the various
testing working groups in the UCA and WG 14 as well as NIST TCC. The
resulting standardized CIM test cases and test procedures were designed to
enable testing in multiple labs at multiple arbitrary times throughout the year.
The CIM Interoperability and Conformance Test Procedure project developed
interoperability test cases and test procedures to test 61968 - 9 messages
applicable to scheduled meter reads, on demand meter reads, meter outages,
meter tamper detection, and remote meter connections and disconnections.
Interoperability test procedures for the IEC 61968 series of standards were
created for submission to the IEC TC 57 for adoption as an interoperability
testing standard. The interoperability test procedures were developed in
coordination with the WG 14 Testing Group, the OpenSG Enterprise and Edge
Conformity groups, the CIM Users Group Interoperability group and the NIST
Testing and Certification Committee. The interoperability test procedures
conform to the IPRM and all applicable International Organization for
Standardization (ISO) standards.
Interoperability test procedures were developed for implementations using an
Enterprise Service Bus (ESB) and for implementations not using an ESB.
As shown in Figure 3-1, there are five Part 9 functional test areas:

Scheduled Meter Read

On Demand Meter Read

Meter Outage Detection

Meter Tamper Detection

Remote Meter Connect/Disconnect

3-1

Figure 3-1
IEC 61968 - 9 Test Cases

Methodology
The CIM Interoperability and Conformance Test Procedure project followed
best practice system engineering principals to develop the IEC 61968 - 9 test
cases and test procedures.
Best practice system engineering for test case and test procedure development
includes the following documentation and project development principles:

Test Plan
-

Test Cases
-

Overall plan defining goals, schedule and expected outcome of the test
program
Includes stakeholder roles and responsibilities
Defines test objectives and units under test (UUTs)
Includes test requirements and requirement traceability matrix (RTM)

Test Procedures
-

Detailed step-by-step instructions to execute formal tests

Includes test setup, data recording and test data sets

3-2

Test Report
-

Documents Test Results

Lists test discrepancies and status of corrective actions

Using the best practices shown above CIM - 9 tests were developed for
Scheduled Meter Read, On Demand Meter Read, Local Area Outage Detected
by Meters, Tampering Detection, and Remote Disconnect/Reconnect
functionality.
The standard sequence, development, and relationship of test documentation is
shown in Figure 3-2.

Figure 3-2
Test Artifact Development Sequence

Project Participants
The CIM Interoperability and Conformance Test Procedure project team was
led by EPRI and included members of the sponsoring utilities American Electric
Power, Consumers Energy, and Southern California Edison as well as other
utilities. Other participants included the OpenSG and CIM Users Groups,
utility system manufacturers, EnerNex, and the Boreas Group.

3-3

Figure 3-3
CIM Test Team

Test Tool Overview

In order to enable creation of standardized CIM test cases and procedures, the
EPRI CIM test effort documented the processes and methodology used to
develop the CIM Part-9 tests. As shown below in Figure 3-4, interoperability
and conformance test documents were developed using Universal Modeling
Language (UML) 2.1, Altova XMLSpy 3 and the Enterprise Architect4 (EA)
tool.
A test harness was developed to automate testing. The test harness is designed to
run in a cloud environment. Each vendor will have their own Amazon EC2
instance to run their copy of the test harness. There are several steps required to
create a new instance, but each step is straightforward. Please see the next
section as well as Appendices A and B for details on how to install and run the
test harness.
UML was used to model the test cases and data sequence flows between systems.
EA was uses to produce the UML diagrams. XMLSpy was used to create and
verify the contents of the XSD files needed to support - 9 testing. See Appendix
C for instructions how to use XMLSpy to create the XSD files.
3

XMSSpy is a registered trademark of Altova Software

Enterprise Architect is a product of Sparx Systems Pty Ltd.

3-4

custom Test Model

EPRI CIM Test Plans

trace
EPRI CIM Interoperability Abstract Test Cases

trace

trace
EPRI CIM Conformance Abstract Test Cases

trace

EPRI CIM Interoperability Test Procedures

EPRI CIM Conformance Test Procedures

Figure 3-4
CIM Test Documentation Set

Test Bed and Test Harness

An important advance developed by the CIM Interoperability and Conformance
Test Procedure project is the ability to perform CIM testing any time, from
anywhere using the Amazon cloud web services. As shown in Figure 3-5, utilities
and system developers can conduct CIM - 9 tests using their on-site test
facilities. For example, a utility can perform an interoperability test using systems
running in their facility, as well as systems running at either other utilities or at
system developers sites. Further, vendors can verify interoperability of their
systems directly from their own test facilities before starting the formal
certification process.

3-5

Figure 3-5
CIM Cloud Computing Environment

3-6

Section 4: CIM Part 9 Test Suite

The set of Part 9 test procedures, grouped by test functionality, are described in
this section. The process used to develop these interoperability test procedures is
standardized to allow development of future test procedures for other parts of the
CIM. The process starts with selection of a Part 9 CIM object is to test. Next the
test description, unit under test (UUT) diagram and expected test results from
the applicable test or use case are added. The requirements from the use cases are
then listed, as well as relevant CIM and OpenSG documentation such as Web
Service Definition Language (WSDLs) service definitions. Lastly detailed test
steps are written including a method to verify each test step.
The steps used to develop the CIM Part 9 interoperability tests are shown below
in Figure 4-1. Each functional test area and test procedure is described briefly
below.

Figure 4-1
CIM Interoperability Test Development Sequence

4-1

Scheduled Meter Read Tests

The scheduled meter read tests verify the ability of AMI systems to perform
remote meter reads under both nominal and error conditions.
ECITP 2.01 Scheduled Meter Read Nominal Interoperability
The ability to schedule meter reads from a CIS (or similar system) to a Meter
Data Management System (MDMS) or Head End (or similar system) is
validated for the systems under test. Standard IEC 61968 Part 9 meter messages
to/from the MDMS and from/to the Customer Information System (CIS) are
used to 1) schedule meter reads for a specific time and 2) read meter usage and
billing data for multiple meters.
The main test steps are as follows:
1. The MeterReadSchedule message is sent from the CIS/other system to the
MDMS to request meter usage data for a scheduled meter read
2. The CreatedMeterReading is sent from the AMI meter/simulator to the
MDMS and onto the CIS.
ECITP 2.02 Scheduled Meter Read System Errors
The ability to recover from common anticipated errors during the meter read
process is a basic interoperability requirement of utility systems. Systems tested
include the Customer Information System (CIS), or similar system; the Meter
Data Management System (MDMS) or Head End (or similar system); and the
meters.
The main test steps are as follows:
1. The MeterReadSchedule message is sent from the CIS/other system to the
MDMS to request meter usage data for a scheduled meter read
2. The meter simulator (or actual meter) is used to inject errors in the returned
meter reading data. Errors injected are:
a) Missing data for 1 meter on a daily read schedule
b) Incomplete data for 1 meter on a daily read schedule (may need to be
tested in conformance test)
c) Missing data for a meter on an hourly read schedule
3.

The MDMS is monitored to ensure it detects the meter read errors

On Demand Meter Read Tests

The on-demand meter reads test verify the ability of AMI systems to perform
remote on-demand meter reads under both nominal and error conditions.

4-2

2.03 On Demand Meter Read Nominal Interoperability

The ability to perform on-demand meter reads is a basic interoperability
requirement of utility systems. Systems tested include the Customer Information
System (CIS), or similar system, and the Metering System (Head-End). Some
AMI system configurations will relay the messages through the Meter Data
Management System (MDMS) which can perform filtering functions. The OnDemand Meter Data Read Interoperability Test verifies that the MS returns the
correct response CreatedMeterReadings message corresponding to the
CreateMeterReadings request message.
The main test steps are as follows:
1. The CreateMeterReading message is sent from the CIS/other system to the
Head-End (possible using the MDMS as an intermediary) for an ondemand meter read
2. The MDMS is monitored to ensure that the on-demand meter read has the
correct format and content
2.04 On Demand Meter Read System Errors
The ability to recover from common anticipated on-demand meter read errors is
a basic interoperability requirement of utility systems. Systems tested include the
Customer Information System (CIS), or similar system; the Head End; and
optionally the Meter data Management System. The (On-demand)
MeterReading Message and XML Errors Test verifies that the MDMS and
related systems recover from common errors expected to occur including missing
and incomplete data.
The ability to perform on-demand meter reads from a CIS (or similar system) to
a Head End is validated for the systems under test. Standard IEC 61968 - 9
meter messages to/from Head-end and from/to the Customer Information
System (CIS) (and optionally to/from the Meter Data Management System
(MDMS)) are used to perform the meter read.
The IEC 61968 - 9 message sequence is as follows:
1. The MeterReadings message is sent from the CIS/other system to the HeadEnd to request meter data (possibly relayed though the MDMS). The
required IEC 61968 - 9 eXtensible Markup Language (XML) Schema
Definition (XSD) is used to send the MeterReadings message.
Errors include:
1. Incorrect meter identifier from OMS (or similar system)
2. Incomplete or missing results from meter for example, a meter is powered off

4-3

Meter Outage Tests

The meter outage tests verify the ability of AMI systems to report power outages
under both nominal and off-nominal conditions.
2.05 Meter Outage Nominal Interoperability
The ability to detect outages sent by meter last gasps is an expected feature of
smart meters and Outage Management Systems (OMS). Systems tested include
the OMS or similar system; the Meter Data Management System (MDMS) or
Head End (or similar system); and the meters. In the IEC 61968 - 9
documentation outage examples, outage detection is performed by the Meter
Reading Meter System (MR-RMR-MS). A Meter Data Management
(MDM) System (MDMS) is shown as an optional component.
The Meter Outage Nominal Interoperability Test verifies that the OMS and
related systems can report outages based on outage detection performed by smart
meter systems.
The ability of the meter system and an Outage Management System (OMS) to
detect and report electric power outages with or without an MDMS or Head
End (or similar system) is validated for the systems under test. Standard IEC
61968 - 9 meter messages to/from the Meter System (MS) and from/to the
OMS are used to report outage for multiple meters. Single point of failure and
nested outages where multiple failures have caused power outages are simulated.
The systems response to the simulated failures is validated. Note that 2009
published version of IEC 61968 - 9 does not currently mandate use of any
particular error codes, but does provide sample error codes.
The IEC 61968 - 9 meter messages transmitted and the message sequence is as
follows:
1. The EndDeviceEvent message is generated by the meter in response to a
simulated power failure. The Meter System detects the failure and sends an
EndDeviceEvent to the OMS. The OMS is monitored to verify that the
meter failure is detected and an outage is declared.
The required IEC 61968 - 9 eXtensible Markup Language (XML) Schema
Definition (XSD) is used to send the EndDeviceEvent message.
2. The meter simulator (or actual meters, or a test harness) is used to inject
multiple nested power outages. The OMS is monitored to verify that the
multiple meter failures are detected and an area outage is declared.
3. The simulated power outage is partially corrected with some area(s) still out.
The OMS is monitored to verify that it clears the outage reports for the
simulated area with restored power, and that the multiple meter failures still
existing are detected and reported to the operators.

4-4

2.06 Meter Outage System Errors

The Meter Outage Nominal System Error test verifies that the OMS and related
systems can respond to common errors in outage detection. Errors tested are a
large outage which might overwhelm the systems ability to report outages, and
communications failures occurring during outages.
The ability of the meter system and an Outage Management System (OMS) to
1) correctly respond to large outages and 2) communications failures combined
with outages is tested. Standard IEC 61968 - 9 meter messages to/from the
Meter Data Management System (MDMS) and from/to the OMS are used to
report outages for large number of meters.
Multiple points of failure causing outages and communications failures are
simulated. The systems response to the simulated failures is validated. Note that
currently published version of IEC 61968 - 9 does not currently mandate use of
any particular error codes, but does provide sample error codes.
The IEC 61968 - 9 meter messages transmitted and the message sequence are as
follows:
1. The EndDeviceEvent message is generated by multiple meters in response to
simulated power failures for 2000 meters. The Meter Data Management
System detects the multiple failures and sends an EndDeviceEvent to the
OMS. The OMS is monitored to verify that the meter failures are detected
and an outage is declared.
2. The meter simulator (or actual meters, or a test harness) is used to simulate
communications failure during the simulated power outage. The OMS is
monitored to verify that the communications failures are detected and
reported.
3. The simulated power outage is partially corrected with communications
failures still present. The OMS is monitored to verify that it reports accurate
status. The communications failures are then removed and the OMS
monitored.
Meter Tampering Detection Tests
The meter tampering detection tests verify the ability of AMI systems to report
meter tampering under both nominal and off-nominal conditions.
2.07 Meter Tampering Detection Nominal Interoperability
The ability to detect meter tampering is a basic interoperability requirement of
utility systems. Systems tested include the Customer Information System (CIS),
or similar system, Meter Data Management System (MDMS), and the Metering
System (Head-End). The Meter Tampering Interoperability Test verifies that
the MS returns the correct response CreatedEndDeviceEvents message
corresponding to the tampering events.
4-5

The ability to perform tampering detection to the CIS (or similar system) and to
the Head End (or similar system) is validated for the systems under test.
Standard IEC 61968 - 9 EndDeviceEvent messages from the head-end to the
MDMS and from the MDMS to the CIS (or similar system) are verified for one
or more meters.
Note that the message sent from the meters need not be based upon CIM
standards. Also note the use case only states that the CIS systems have access to
the tampering events and does not specify specific messages. For example, the
head-end could indicate a Cover removal detected tamper event while the
MDMS could indicate to the CIS system a Tamper Indication event.
2.08 Meter Tampering Detection System Errors
The ability to perform tampering detection when system errors are inserted at the
CIS (or similar system) and at the Head End (or similar system) is validated for
the systems under test. Standard IEC 61968 - 9 EndDeviceEvent messages
from the head-end to the MDMS and from the MDMS to the CIS (or similar
system) are verified for one or more meters.
The IEC 61968 - 9 EndDeviceEvent messages are transmitted with errors and
the ability of the systems to tolerate errors is tested. Note that the messages sent
from the meters do need not be based upon CIM standards. Also note the use
case only states that the CIS systems have access to the tampering events and
does not specify specific messages. For example, the head-end could indicate a
Cover removal detected tamper event while the MDMS could indicate to the
CIS system a Tamper Indication event.
Meter Disconnect/Reconnect Tests
The meter disconnect/reconnect tests verify the ability of AMI systems to
perform remote meter disconnects and reconnects under both nominal and error
conditions.
2.09 Meter Disconnect/Reconnect Nominal Interoperability
The ability to remotely disconnect and reconnect meters from the power
distribution system is functionality desired by many utilities. The CIS or similar
system will direct the Meter Data Management System (MDMS) or Head End
(or similar system) to remotely direct the meters to disconnect or reconnect to the
power distribution system. Disconnected meters physically will not allow power
to flow. In the IEC 61968 - 9 disconnect/reconnect examples
EndDeviceControls messages are performed by the Meter Data Management
(MDM) System (MDMS).
The Meter Disconnect/Reconnect Nominal Interoperability Test verifies that the
CIS and related systems can remotely direct meter connections and
reconnections. Actual meters, if available, may be used in the test system. Note
that potential safety hazards associated with disconnecting power e.g. for
4-6

customers using medical devices or with reconnecting power e.g. activation of

devices such as electric stoves when no adult is present are not covered by this test
procedure.
The IEC 61968 - 9 meter sequence is as follows:
1. The MeterServiceRequest message is sent from the CIS to the MDMS.
2. The EndDeviceControls message is sent from the MDMS to the AMI Head
End or similar system.
3. The meter performs a remote disconnect.
4. The MeterReadings message is sent from the MDMS to request meter usage
data for the meter.
5. The CreatedMeterReading is sent from the meter/simulator to the MDMS
and onto the CIS.
2.10 Meter Disconnect/Reconnect System Errors
The ability of the CIS to remotely command meter disconnections and
reconnections when communications errors are present validated for the systems
under test. Standard IEC 61968 - 9 meter messages to/from the Meter System
(MS) and from/to the CIS are used to command the meter disconnections and
reconnections. Communications errors are injected and the systems monitored to
verify that message retries are attempted. For meters with hard communications
errors a work order to manually connect/disconnect the meter is expected. The
amount of energy on the meter at the time of disconnect/reconnect is reported
with the MeterReading message.
1. The MeterServiceRequest disconnect message is sent from the CIS to the
MDMS.
2. A communications error to the meter is simulated, thus the
EndDeviceControl disconnect message sent from the MDMS to the AMI
Head End and on to the meter is not received.
3. The message traffic is monitored to verify that message retries are attempted
for the meter disconnect message.
4. The communications error is removed and the system monitored to verify
that the MeterReadings message is sent from the MDMS to request meter
usage data for the meter.
5. The CreatedMeterReading is sent from the meter/simulator to the MDMS
and onto the CIS. The required IEC 61968 - 9 XSD is used to send the
CreatedMeterReading message.
6. Another meter disconnect message is sent to a different meter. A
communications error is injected which does not clear simulating a hard loss
of communications.
7. System is monitored to verify that a work order is generated to send a field
technician to the field to manually disconnect the meter.
4-7

8. The above test sequence is repeated for the meter reconnect message. The
MeterServiceRequest reconnect message is sent from the CIS to the
MDMS.
9.

A communications error to the meter is simulated, thus the

EndDeviceControl reconnect message sent from the MDMS to the AMI
Head End and on to the meter is not received.

10. The message traffic is monitored to verify that message retries are attempted
for the meter reconnect message.
11. The communications error is removed and the system monitored to verify
that the MeterReadings message is sent from the MDMS to request meter
usage data for the meter.
12. The CreatedMeterReading is sent from the meter/simulator to the MDMS
and onto the CIS.
13. Another meter reconnect message is sent to a different meter. A
communications error is injected which does not clear simulating a hard loss
of communications.
14. System is monitored to verify that a work order is generated to send a field
technician to the field to manually reconnect the meter.

4-8

Section 5: Recommendations
During the process of developing the CIM test methodology, test procedures,
and test harness, several challenges and potential follow-on efforts were identified
which would help advance the CIM. Challenges to the CIM implementation
and CIM test effort include:

An out-of-date standard last published in 2009

A lack of consensus on whether the CIM should be used on a per utility basis
or across multiple utilities

A lack of a concrete framework for implementing the CIM and the inherent
difficulty of expanding a standard that successfully transfers Transmission
and Distribution system models into one which can transfer T&D
operational, as opposed to system model, information in near real time.

Each challenge is summarized here along with recommendations on how to best

proceed with CIM in order to increase the number of utilities and vendors
benefitting from CIM implementation.
The first challenge is an out-of-date Part 9 CIM last published in 2009. The
formal IEC standard process is lengthy and thus slow which prevents usable upto-date versions of the CIM from being available for purchase. Development and
subsequent testing of Part 9 applications typically require use of the latest Part 9
version which is not yet publically available. A method which allows both utilities
and vendors to acquire current versions of the CIM specifications is required in
order to implement the CIM without the use of expensive consultants who have
inside knowledge of CIM version changes.
Possible solutions include testing only the publically released IEC versions of the
CIM and the use of backwardly and forwardly compatible versions of the CIM.
Although testing only with published versions might appear to slow CIM
development, it would increase the number of utilities and system developers
who could implement the current known version of the CIM rather than the
future unapproved version.
Second, the concept that of IEC 619868 - 9 furthers interoperability by
providing an information model usable for a single utility needs to be expanded.
IEC 619868 - 9 needs to be specify data models and data message which are
interoperable among multiple utilities as is the case for the CIMs Power System
Model. Some tailoring of the CIM to specific conditions might well still be
required; however, the current use of an abstract CIM model which requires a
5-1

custom implementation at each utility negates any potential advantage of

implementing a standardized interface. For example, meter error codes needed
to be standardized among various meter vendors in order for meter, MDMS and
OMS vendors as well as the utilities who purchase these systems to benefit from
the CIM.
Further best practices for common information models define both the
information as it is stored and the information as it is transmitted. Thus the IEC
CIM - 9 should specify both data content in terms of data item descriptions,
units, precision, ranges and limitations of data usage, as well as specifying
standard CIM data exchange messages.
Lastly a workable definition of CIM compliant is needed. The CIM is a large
specification contained in a dozen or more IEC specifications so it would be
difficult for any given product to be compliant with all of the CIM specifications
However, the current practice of executing tests with a very limited and in some
cases, single CIM message, will not produce reusable systems which can be easily
integrated.
Without a standardized method of designing, developing, testing, and certifying
a set of messages for subsets of the CIM, the CIM cannot be used by either
utilities or vendors to further interoperability. Nor can the CIM reduce the cost
of integration or allow vendors to leverage product development across multiple
installations. It is the intent of this report to specify a subset of CIM Part 9
messages to demonstrate basic meter interoperability. Further, work is needed to
define standard messages for other CIM parts beyond the Power System Model
and to develop a certification capability which will establish an open and reliable
testing mechanism to ascertain the conformance of an application to a standard.

5-2

Appendix A: EPRI Interoperability Test

Harness How-To-Deploy
Tutorial
Introduction
The test harness is designed to run on a cloud environment. Each vendor will
have their own Amazon EC2 instance to run their copy of the test harness.
There are several steps required to create a new instance, but each step is
straightforward.
Amazon EC2 is a cloud environment that makes it simple to create, manage, and
deploy web based applications. Its an excellent choice for hosting the test
harness, as it is easy to generate new instances on demand. Also, the service itself
is extremely reliable. The cloud is an affordable option. The test harness has a
very small footprint, which means that the lowest cost services are sufficient.
Getting Started
In order to use the Amazon EC2 service, you must have an AWS(Amazon Web
Services) account, with the EC2 functionality enabled. The signup process is
quite simple and is available at the following URL:

http://aws.amazon.com/console/
Once you have an account, enable the EC2 feature: simply click on the EC2 tab
and a wizard will walk you through the process to enable your account.
Instance Creation Steps
We will use the Instance Creation wizard to deploy new instances. A complete
walkthrough of the process is given below.

A-1

Creating a new test harness instance

First, log into the AWS management console and select the EC2 tab. Click on
the INSTANCES entry in the Navigation bar. This will bring up the list of all
available instances, along with their current status (running/not running).

Figure A-1
EC2 Instance View

To create a new instance, click on the Launch Instance button, indicated by the
red arrow above. This will bring up the Request Instances Wizard page.

Figure A-2
Request Instances Wizard, Choose An AMI

A-2

In the Request Instances Wizard, Choose An AMI step, choose the first option,
Basic 32-bit Amazon Linux AMI Beta.

Figure A-3
Request Instances Wizard, Instance Details

In the next step, Instance Details, select the Instance Type. The test harness uses
the Micro instance. Set Number of Instances to 1, and Availability Zone to No
Preference, then click Continue. This will bring up the Advanced Instance
Options dialog.

A-3

Figure A-4
Request Instances Wizard, Instance Details, Advanced

In this dialog, accept the defaults, but update the User Data section to something
meaningful, like the actual vendor name for this instance (Company1,
Company2, etc). It will make identifying the instance easier, when there are
many listed in the home page. Then click Continue, which will bring up the Key
Tags page.

A-4

Figure A-5
Request Instances Wizard, Instance Details, Tags

This dialog allows the user to enter key-value tags to further help manage the
instances. In this dialog, create a key-value pair called Name, with the same
value that was used in the previous dialog. Click Continue to bring up the
Create KeyPair dialog.

Figure A-6
Request Instances Wizard, Create Key-Pair

A-5

A Key-Pair controls access to the instance. For simplicity, use the same key-pair
for each instance. Then there is no need to hunt down the correct key-pair.
However, separate key-pairs can be set up for each instance if desired. There
should be an existing key-pair called interop_test in the pull-down list. Choose
this entry and click Continue to bring up the Configure Firewall dialog. Once
created download the key-pair for local use.
The EPRI EC2 account has a key-pair already generated, named interop_test.
This key-pair must be used when creating test harness instances, as the
deployment server relies upon it.

Figure A-7
Request Instances Wizard, Configure Firewall

The Configure Firewall dialog controls which ports are open to the instance.
Typical ports are 80(http), 8080(web services), 22(ssh), etc. Your account was
already configured with a SecurityGroup called web services, which opens the
following ports:
22 ssh
80 http
8080 - 8085 web services
3000 UI debugging
Choose the web service security group and click Continue to bring up the Review
dialog.

A-6

Figure A-8
Request Instances Wizard, Review

Click the Launch button to start the instance. This return the user to the EC2
list of instances dialog.

Figure A-9
Request Instances Wizard, My Instances

A-7

The newly created instance will appear in the list with a Name value of the value
entered on the Key-Value page and a Status of pending. The Status value will
eventually change to running.

For easy identification, if the Name field is incorrect, mouse over the Name
and click the pencil icon that appears to edit the text.

Enter the vendor name in the field and choose Save. The Name field will be
changed to the entered value. This is the simplest way to identify each instance
in the list.

Figure A-10
Request Instances Wizard, Vendor Naming

A-8

Figure A-11
My Instances, Instance Management

Available options are indicated by the red arrow and will change, depending on
the current state of the instance. The Terminate option will delete the
instance. Click on the name (but not the edit icon, to display more instance
details.

A-9

Figure A-12
Specific Instance Details, Showing Public DNS

Its important to understand that a new IP address and a new public DNS name
is assigned each time the instance is restarted. The public DNS name is shown
underlined in red. This is the hostname that must be used (as the baseURL
value) in all of the test harness examples. It is the only way for the vendor to
access the test harness. The public DNS name must be given to the vendor as
part of the handoff.
In the future Amazon ElasticIPs could be used to prevent the issue with the
Public DNS name restart. This would require EPRI to allocate some domain
names/hostnames.
Deploying applications to each instance
Now that the instance has been created and is running, the test harness must be
deployed. This is a one time process.
Log into the master deployment server instance - you can see it in the list of
instances on the AWS EC2 page. You will need to know the public DNS name,
which you can determine as shown in the previous section. The same key-pair,
interop_test, can be used to access the master deployment server.

A-10

Figure A-13
EC2 instance, Show Master Deployment Server

SSHing Into the Server

EC2 allows only direct SSH access to its instances. The key-pair from above,
interop_test can also be used to access the deployment server. Ssh can be used
from a linux OS, or putty from a Windows server. The openssh key is
interop_test.pem, while the putty key is interop_test.ppk.
Assuming the master deployment public DNS name is ec2.xyz.com, log in with
ssh as follows:
ssh i interop_test.pem ec2_user@ec2.xyz.com
Using putty, open a putty session and enter the ppk file in the authentication tab.

A-11

Figure A-14
Putty session, Authentication Tab

Note: Enter the hostname, ec2.xyz.com, and user account ec2_user.

Using the pem/ppk files will log users directly into the server without asking for a
password.
Once logged in, issue the following commands:
sudo su
The deploy command needs root privileges
cd /deploy
cap setup_instance
This command starts the deployment process. The user will be prompted for the
Public DNS name of the new ec2 instance.

A-12

Below is a typical putty session showing the start of a new instance deployment.
Note that it is prompting the user for the Public DNS name of the new instance.

Figure A-15
Putty session, Showing Deployment in Progress

After entering the Public DNS name of the new instance, the script will take
some time to configure the server, at least 10 to 15 minutes. Once complete, the
new instance (and test harness) is ready to use.
Verify Test Harness is Functioning
Verify test harness availability by browsing to the following URLs.
http://Public DNS name of vendor instance
The browser should display the current test harness UI reporting information:

Figure A-16
Reporting UI

A-13

http://Public DNS name of vendor:8080/epriConnect

This displays a list of available web services.

Figure A-17
Browser View of Web Services

A-14

Appendix B: EPRI Interoperability Test

Harness Tutorial
Introduction
soapUI is one of the leading web service test tools and provides a novel,
affordable method for easily testing communication interoperability between
systems. To demonstrate the efficacy of soapUI, project files have been provided
that will allow the user to exercise the test harness without writing any actual
code and provide clear working examples of how to interact with the test harness.
For this tutorial, each test package is broken into a set of interfaces, with one
soapUI project per interface.
soapUI can be obtained from http://www.soapui.org/. Note that the examples
and screenshots in this documentation were made with version 3.6.1, and the
look and feel may differ slightly from subsequent versions.
Getting Started
In order to use the test harness, a vendor must request an instance from EPRI.
After completion of the form and specification of vendor type, EPRI will create
an instance and return a base URL to the vendor (for example: . ec2-107-20-45188.compute-1.amazonaws.com ).
Validate Connectivity
To verify the test harness instance is active, enter the following into a browser,
substituting baseurl with the URL assigned by EPRI:

http://baseurl:8080/epriConnect/
The URL should display a page similar to Figure B-1, confirming that the
services are available and ready for use.

B-1

Figure B-1
List of Available Web Services

Loading a project into soapUI

Download and start soapUI. Within the test package there will be a directory
named /soapUI/. Within that directory are several *.xml project files. The file
naming convention is testpackage-vendor-interface#.xml.
Click on File/Import Project to load a project. Once loaded, it will remain as an
active project unless explicitly removed. For this example, use an actual project.
Because all projects are similar, this will serve as detailed documentation for all
the projects.

Figure B-2
soapUI file browser

B-2

Browse to the soapui/ directory and choose one of the project files for this
example, choose MeterConnect-CIS-1.xml. Once loaded, it should appear in the
navigator bar, Figure B-3.

Figure B-3
SoapUI with Project in Navigator Bar

For this interface, there is one incoming message that the test harness will
validate Test package Meter Connect, CIS interface 1. The interfaces have been
numbered for easier reference within the test. In this example, the vendor role is
CIS, with the test harness in the role of MDMS and AMI head-end.

B-3

Figure B-4
Meter Connect package UML diagram

Figure B-4 shows the UML diagram for the Meter Connect test package. Note
interface 1, which involves the CIS vendor sending in a connect/disconnect
request to the MDM (test harness).
Using soapui
EPRI also includes a web-based reporting user interface that displays the results
of test progress. To view the test results, browse to:
http://baseurl.
The URL will display a screen similar to that shown in Figure B-5.

B-4

Figure B-5
Web UI home page

Note that all percentages are currently 0%, as this is the first time using the
instance. There are four boxes on the home page, one for each vendor role
in this example, all roles are enabled.

Each message to be validated has both a successful and unsuccessful test example
in the project. To simulate the message request, go to soapUI and click on the
CreatedMeterServiceRequests TestCase, then on TestSteps.

Figure B-6
SoapUI, meter service requests

B-5

Note the two test steps (highlighted by red in Figure B-6),

CreatedMeterServiceRequests, CreatedMeterServiceRequests Fail.

Failed Message Communication Example

To demonstrate sending in an invalid message to the test harness, double-click
on the CreatedMeterServiceRequests Fail test. This will display the details of the
outgoing message.

Figure B-7
SoapUI, modifying the endpoint url

Note the endpoint address, highlighted next to the red indicator in Figure B-7.
This endpoint must be modified to point to the actual EC2 instance, using the
base URL.
Click on the endpoint pulldown, and choose add new endpoint from the menu,
as in Figure B-8.

Figure B-8
SoapUI, endpoint menu

B-6

As Figure B-9 shows, in the Add new endpoint popup, replace the hostname
with the base URL name (within the blue highlight), and click OK. The test is
now pointed to the EC2 vendor instance the endpoint for this test will not
need to be changed again. Make sure the endpoint url agrees with the value
specified in the package documentation at the end of this document. The default
soapUI project files should have the correct endpoints already.

Figure B-9
SoapUI, editing the endpoint url

To send the test message to the EC2 instance, click on the green arrow in the left
of the menu bar.

Figure B-10
SoapUI, sending Meter Service request message

The server should respond with the failed message in Figure B-11.

B-7

Figure B-11
SoapUI failed message response

In this example, because there was a problem with the actual formatted .xml
message, the error returned will give the line number of the offending message
data. The error messages do not always pinpoint the exact line number, but
generally give enough information to determine the cause of the problem.
Navigate to the WebUI for the test results and refresh the browser page.

Note that there is no change in % complete.

Figure B-12
WebUI, home page with 0% success

Click on the MeterConnect label, to navigate to the detailed log page for the
package, as shown in Figure B-12.
B-8

Figure B-13
WebUI, failed service request in package view

The Package Status displays that the latest invocation of the meter service
request failed. Clicking on the Logs link will display the detailed log view of
the interface.

Figure B-14
WebUI failed service request log listing

Clicking on the Show link will display all details of the logged service call. In
this example, the serviceIn log shows the details of the incoming message, while
the serviceOutFault shows the details of the actual error.

B-9

Figure B-15
WebUI incoming log for failed request

Figure B-16
WebUI response message to failed message

B-10

Successful Message Communication Example

soapUI will also return information on successful messages. Similar to the
previous demonstration, in the navigation bar, click on the
CreatedMeterServiceRequests test step (non fail). This is a well formatted message
that the server will be able to parse successfully.
As with the Fail message, change the endpoint to the EC2 instance name.

Note that there is no need to re-add the endpoint, it can be selected from the
pulldown now

Click the green button to send the request to the server. This time, the server
responds with a successful message in Figure B-17.

Figure B-17
SoapUI successful message response

B-11

Navigate to the WebUI for reporting and refresh the browser.

Note that the % complete for MeterConnect is now 33%

Figure B-18
WebUI 33% complete

Click on the MeterConnect label to view the package status.

Figure B-19
WebUI success for interface 1.

B-12

Click through again to the log entries.

Figure B-20
WebUI listing of log entries

Note the latest pair of messages has a value of success in the ResultCode field.
Incoming Messages
In the MeterConnect CIS example, there are 3 messages: one outgoing from
CIS, and two incoming messages. The previous section demonstrates how to
send a message to the EC2 instance to be parsed. For the next two examples
soapUI will be used to request a message to be returned.
Open the MeterConnect CIS -2 project in soapUI. There should be two
projects in the navigation bar, as seen in Figure B-21.

Figure B-21
SoapUI loading MeterConnect CIS-2 project

In order to receive the message, a service must be made available. In soapUI, this
is done by using a mock service.

Important note: The user will need a public IP/hostname in order to receive
a message from the cloud. However, if a static IP is unavailable, or the user
is behind a NAT firewall, port forwarding (See port forwarding section) will
allow the messages to be received. For now, it is assumed that a public
hostname and appropriate open ports are available.
B-13

Starting the CIS Mock Service

Figure B-22
SoapUI mock service start

In the MeterConnect CIS-2 project, double-click on the

ReplymeterServiceRequests_Binding MockService to open the mock service dialog.
Then, click on the options button to change the local binding.

Figure B-23
Mock service options

In the MockService Options dialog, the user can change the port number, as well
as the localhost name. Note them down for the purposes of this test soapUI
will bind to the port on the machine that it executes on by default.
Click the green start arrow in the menu bar to start the mock service. To make
space, minimize the window or, right click in the navigation bar and choose
Start Minimized as in Figure B-24.

B-14

Figure B-24
SoapUI Mock service menu, start minimized

Double-click on the minimized mock services window to expand it. Note that
the message log is empty, as shown in Figure B-25.

B-15

Figure B-25
SoapUI. Mock service, no messages

Requesting the Message

In order to request a test message to be sent to soapUI, click on
RequestMessageServiceRequests_Binding TestSuite, then
CreateMeterServiceRequests TestCase, then Test Steps(1), then
CreateMeterServiceRequests.

B-16

Figure B-26
Sending message request, changing reply address

The endpoint must be changed to point to the EC2 instance, as before. In the
actual message body, edit the reply address to the users public hostname or IP
address. This is the address to which the EC2 instance will send the message.
In this case, it will point to the machine running soapUI(and the mock service
which will receive the message).

Note that the opportunity exists to change the meter ID and any other fields
as needed, however for this example, just change the address

Click on the green arrow to send the request to the test harness, which will then
send a message back to the reply address which is being served by the mock
service.
Double-click on the minimized mock services window to display it.

B-17

Figure B-27
SoapUI, mock services showing received message

The highlighted line in this dialog (Figure B-27) indicates that a message was
received. To see the actual message returned, double-click on the line.

B-18

Figure B-28
SoapUI received message from mock service

Note in the WebUI in Figure B-29, the CIS MeterConnect package now
shows 67% complete.

Figure B-29
SoapUI home page showing 67% complete

Click the MeterConnect link to see the individual interface status.

B-19

Figure B-30
SoapUI package status showing success

All packages are composed of these two types of messages outgoing messages
to be validated by the test harness, or request messages that cause the test
harness to send back a message in response.

B-20

Meter Connect Package

Each test package contains a simplified description of the services and soapUI
project names for each interface. Follow the instructions above to change
endpoints/reply address as appropriate for each.

Figure B-31
Meter Connect package, UML diagram

B-21

CIS
1. CIS sends a CREATE(#1 MeterServiceRequest) request
SoapUI Project File:
MeterConnect CIS-1.xml
Tag:
MD_CIS-MDM_Create(MeterServiceRequest)
Endpoint:
http://baseurl:8080/epriConnect/mdms/cis/send
WSDL:
SendMeterServiceRequests
SoapUI:
SendMeterServiceRequests_Binding TestSuite/
CreatedMeterServiceRequests TestCase/
Test Steps/
CreatedMeterServiceRequests
CreatedMeterServiceRequests Fail
2. Provide hook to send meter service request REPLY(#2 MeterServiceRequest)
SoapUI Project File:
MeterConnect CIS-2.xml
Tag:
MD_CISMDM_Request_Reply(MeterServiceRequest)
Endpoint:
http://baseurl:8080/epriConnect/connect/mdms/cis/request
WSDL:
ReplyMeterServiceRequests
Request WSDL:
RequestMeterServiceRequests
SoapUI Mock Service:
ReplyMeterServiceRequests_Binding MockService
SoapUI request:
RequestMeterServiceRequests_Binding TestSuite/
CreateMeterServiceRequests TestCase/
TestSteps/
CreateMeterServiceRequests
3. Provide hook to send updated meter service request Updated(#8
MeterServiceRequest)
SoapUI Project File:
MeterConnect CIS-3.xml
Tag:
MD_CISMDM_Request_Updated(MeterServiceRequest)
Endpoint:
http://baseurl:8080/epriConnect/mdms/cis/requestUpdate
WSDL:
ReplyMeterServiceRequests
Request WSDL:
RequestMeterServiceRequests
SoapUI Mock Service:
ReplyMeterServiceRequests_Binding MockService
SoapUI request:
RequestMeterServiceRequests_Binding TestSuite/
CreateMeterServiceRequests TestCase/
TestSteps/
CreateMeterServiceRequests
B-22

MDMS
1.. Provide hook to generate meter service request CREATE(#1
MeterServiceRequest)
SoapUI Project File:
MeterConnect MDMS-1.xml
Tag:
MD_MDMCIS_Request_Create(MeterServiceRequest)
Endpoint:
http://baseurl:8080/epriConnect/cis/mdms/requestCreate
WSDL:
SendMeterServiceRequests
Request WSDL:
RequestMeterServiceRequests
SoapUI Mock Service:
SendMeterServiceRequests_Binding MockService
SoapUI request:
RequestMeterServiceRequests_Binding TestSuite/
CreateMeterServiceRequests TestCase/
TestSteps/
CreateMeterServiceRequests
2. MDMS sends a REPLY(#2 MeterServiceRequest)
SoapUI Project File:
MeterConnect MDMS-2.xml
Tag:
MD-MDM-CIS_Reply(MeterServiceRequest)
Endpoint:
http://baseurl:8080/epriConnect/cis/mdms/reply
WSDL:
ReplyMeterServiceRequests
SoapUI:
SendMeterServiceRequests_Binding TestSuite/
CreatedMeterServiceRequests TestCase/
Test Steps/
Success
Fail
3. MDMS sends CREATE(#3 EndDeviceControls)
SoapUI Project File:
MeterConnect MDMS-3.xml
Tag:
MD_MDM-AMI_Create(EndDeviceControls)
Endpoint:
http://baseurl:8080/epriConnect/mdms/ami/send
WSDL:
SendDeviceControls
SoapUI:
SendEndDeviceControls_Binding TestSuite
CreatedEndDeviceControls TestCase
Test Steps
Success
Fail

B-23

4. Provide hook to generate REPLY(#4 EndDeviceControls)

SoapUI Project File:
MeterConnect MDMS-4.xml
Tag:
MD_MDMAMI_Request_Reply(EndDeviceControls)
Endpoint:
http://baseurl:8080/epriConnect/mdms/ami/requestReply
WSDL:
ReplyDeviceControls
Request WSDL:
RequestEndDeviceControls
SoapUI MockService:
ReplyEndDeviceControls_Binding MockService
Soap Request:
RequestEndDeviceControls_Binding TestSuite
CreateEndDeviceControls TestCase
TestSteps
TestRequest
5. MDMS sends CREATE(#5 MeterReadings)
SoapUI Project File:
MeterConnect MDMS-5.xml
Tag:
MD_MDM-AMI_Create(MeterReadings)
Endpoint:
http://baseurl:8080/epriConnect/mdms/ami/sendMeterRead
WSDL:
SendMeterReadings
SoapUI:
SendMeterReadings_Binding TestSuite
CreatedMeterReadings TestCase
Test Steps
Success
Fail
6. Provide hook to generate REPLY(#6 MeterReadings)
SoapUI Project File:
MeterConnect MDMS-6.xml
Tag:
MD_MDMAMI_Request_Reply(MeterReadings)
Endpoint:
http://baseurl:8080/epriConnect/connect/mdms/ami/requestMeterReading
WSDL:
ReplyMeterReadings
Request WSDL:
RequestMeterReadings
SoapUI Mock Service:
ReplyMeterReadings_Binding MockService
SoapUI Request:
RequestMeterReadings_Binding TestSuite
CreateMeterReadings TestCase
TestSteps
CreateMeterReadings

B-24

7. Provide hook to generate meter readings CREATED(#7 MeterReadings)

SoapUI Project File:
MeterConnect MDMS-7.xml
Tag:
MD_MDMAMI_Request_Created(MeterReadings)
Endpoint:
http://baseurl:8080/epriConnect/connect/mdms/ami/requestMeterReading2
WSDL:
ReplyMeterReadings
Request WSDL:
RequestMeterReadings
SoapUI Mock Service:
ReplyMeterReadings_Binding MockService
SoapUI Request:
RequestMeterReadings_Binding TestSuite
CreateMeterReadings TestCase
Test Steps
CreateMeterReadings
8. MDMS sends UPDATED(#8 MeterServiceRequest)
SoapUI Project File:
MeterConnect MDMS-8.xml
Tag:
MD_MDMCIS_Updated(MeterServiceRequest)
Endpoint:
http://baseurl:8080/epriConnect/connect/mdms/cis/reply
WSDL:
SendMeterServiceRequests
SoapUI:
SendMeterServiceRequests_Binding TestSuite
CreatedMeterServiceRequests TestCase
Test Steps
Success
Fail

B-25

AMI
1. Provide hook to generate CREATE(#3 EndDeviceControls)
SoapUI Project File:
MeterConnect AMI-1.xml
Tag:
MD_AMIMDM_Request_Create(EndDeviceControls)
Endpoint:
http://baseurl:8080/epriConnect/connect/ami/mdms/requestCreate
WSDL:
ReplyEndDeviceControls
Request WSDL:
RequestEndDeviceControls
SoapUI Mock Service:
ReplyEndDeviceControls_Binding MockService
SoapUI Request:
RequestEndDeviceControls_Binding TestSuite
CreateEndDeviceControls TestCase
Test Steps
CreateEndDeviceControls
2. AMI headend sends REPLY(#4 EndDeviceControls)
SoapUI Project File:
MeterConnect AMI-2.xml
Tag:
MD_AMI-MDM_Reply(EndDeviceControls)
Endpoint:
http://baseurl:8080/epriConnect/ami/mdms/reply
WSDL:
ReplyEndDeviceControls
SoapUI:
ReplyEndDeviceControls_Binding TestSuite
CreatedEndDeviceControls
Test Steps
Success
Fail
3. Provide hook to generate CREATE(#5 MeterReadings)
SoapUI Project File:
MeterConnect AMI-3.xml
Tag:
MD_AMIMDM_Request_Created(MeterReadings)
Endpoint:
http://baseurl:8080/epriConnect/connect/ami/mdms/requestMeterReading
WSDL:
SendMeterReadings.wsdl
Request WSDL:
SendMeterReadings.wsdl
SoapUI Mock Service:
SendMeterReadings_Binding MockService
SoapUI Request:
SendMeterReadings_Binding TestSuite
CreateMeterReadings TestCase
Test Steps
CreatedMeterReadings
B-26

4. AMI headend sends REPLY(#6 MeterReadings)

SoapUI Project File:
MeterConnect AMI-4.xml
Tag:
MD_AMI-MDM _Reply(MeterReadings)
Endpoint:
http://baseurl:8080/epriConnect/
connect/ami/mdms/reply
WSDL:
ReplyMeterReadings
SoapUI:
SendMeterReadings_Binding TestSuite
CreatedMeterReadings TestCase
Test Steps
Success
Fail
5. AMI headend sends CREATED(#7 MeterReadings)
SoapUI Project File:
MeterConnect AMI-5.xml
Tag:
MD_AMI-MDM_Created(MeterReadings)
Endpoint:
http://baseurl:8080/epriConnect/connect/ami/mdms/send
WSDL:
SendMeterReadings
SoapUI:
SendMeterReadings_Binding TestSuite
CreatedMeterReadings TestCase
Test Steps
Success
Fail

B-27

Meter OnDemand Package

Each test package contains a simplified description of the services and soapUI
project names for each interface. Follow the instructions above to change
endpoints/reply address as appropriate for each.

Figure B-32
Meter OnDemand package, UML diagram

B-28

CIS
1. CIS sends GET(#1 MeterReading)
SoapUI Project File:
MeterOnDemand CIS-1.xml
Tag:
OD_CIS-MDM_Get(MeterReadings)
Endpoint:
http://baseurl:8080/epriConnect/
ondemand/cis/mdms/get
WSDL:
GetMeterReadings
SoapUI:
GetMeterReadings_Binding TestSuite
GetMeterReadings TestCase
Test Steps
Success
Fail
2. Provide hook to send reply send REPLY(#2 MeterReading)
SoapUI Project File:
MeterOnDemand CIS-2.xml
Tag:
OD_CIS-MDM_Reply(MeterReadings)
Endpoint:
http://baseurl:8080/epriConnect/ondemand/cis/mdms/requestMeterReading
WSDL:
ReplyMeterReadings
Request WSDL:
RequestMeterReadings
SoapUI Mock Service:
ReplyMeterReadings_Binding MockService
SoapUI Request:
RequestMeterReadings_Binding TestSuite
CreateMeterReadings TestCase
Test Steps
CreateMeterReadings

3. CIS sends GET(#5 MeterReading)

SoapUI Project File:
MeterOnDemand CIS-3.xml
Tag:
OD_CIS-AMI_Get(MeterReading)
Endpoint:
http://baseurl:8080/epriConnect/ondemand/cis/ami/send
WSDL:
GetMeterReadings
SoapUI:
GetMeterReadings_Binding TestSuite
GetMeterReadings TestCase
Test Steps
Success
Fail
B-29

4. Provide hook to send REPLY(#6 MeterReading)

SoapUI Project File:
MeterOnDemand CIS-4.xml
Tag:
OD_CIS-AMI_Reply(MeterReadings)
Endpoint:
http://baseurl:8080/epriConnect/ondemand/cis/ami/requestMeterReadi
ng
WSDL:
ReplyMeterReadings
Request WSDL:
RequestMeterReadings
SoapUI Mock Service:
ReplyMeterReadings_Binding MockService
SoapUI Request:
RequestMeterReadings_Binding TestSuite
CreateMeterReadings TestCase
Test Steps
CreateMeterReadings
5. CIS sends GET(#7 MeterReading)
SoapUI Project File:
MeterOnDemand CIS-5.xml
Tag:
OD_CIS-MDM_Get(7MeterReadings)
Endpoint:
http://baseurl:8080/epriConnect/ondemand/cis/mdms/get2
WSDL:
GetMeterReadings
SoapUI:
GetMeterReadings_Binding TestSuite
GetMeterReadings TestCase
Test Steps
Success
Fail

6. Provide hook to send REPLY(#8 MeterReading)

SoapUI Project File:
MeterOnDemand CIS-6.xml
Tag:
OD_CIS-MDM_Reply(6MeterReadings)
Endpoint:
http://baseurl:8080/epriConnect/ondemand/cis/ami/requestMeterReading2
WSDL:
ReplyMeterReadings
Request WSDL:
RequestMeterReadings
SoapUI Mock Service:
ReplyMeterReadings_Binding MockService
SoapUI Request:
RequestMeterReadings_Binding TestSuite
CreateMeterReadings TestCase
Test Steps
CreateMeterReadings

B-30

MDMS
1. Provide hook to send GET(#1 MeterReading)
SoapUI Project File:
MeterOnDemand MDMS-1.xml
Tag:
OD_MDM-CIS_Get(MeterReadings)
Endpoint:
http://baseurl:8080/epriConnect/ondemand/mdms/cis/requestGet
WSDL:
GetMeterReadings
Request WSDL:
GetMeterReadings
SoapUI Mock Service:
MockService 1
SoapUI Request:
GetMeterReadings_Binding TestSuite
GeMeterReadings TestCase
Test Steps
GetMeterReadings
2. MDMS sends REPLY(#2 MeterReading)
SoapUI Project File:
MeterOnDemand MDMS-2.xml
Tag:
OD_MDM-CIS_Reply(MeterReading)
Endpoint:
http://baseurl:8080/epriConnect/ondemand/mdms/cis/reply
WSDL:
ReplyMeterReading
SoapUI:
ReplyMeterReadings_Binding TestSuite
ReplyMeterReadings TestCase
Test Steps
Success
Fail
3. MDMS sends GET(#3 Meter Reading)
SoapUI Project File:
MeterOnDemand MDMS-3.xml
Tag:
OD_MDM-AMI_Get(MeterReadings)
Endpoint:
http://baseurl:8080/epriConnect/
ondemand/mdms/ami/send
WSDL:
GetMeterReadings
SoapUI:
GetMeterReadings_Binding TestSuite
GetMeterReadings TestCase
Test Steps
Success
Fail
B-31

4. Provide a hook to generate REPLY(#4 MeterReading)

SoapUI Project File:
MeterOnDemand MDMS-4.xml
Tag:
OD_MDM-AMI_Reply(MeterReading)
Endpoint:
http://baseurl:8080/epriConnect/ondemand/mdms/ami/requestMeterReading
WSDL:
Request WSDL:
SoapUI Mock Service:
ReplyMeterReadings_Binding MockService
SoapUI Request:
RequestMeterReadings_Binding TestSuite
CreateMeterReadings TestCase
Test Steps
CreateMeterReadings
5. Provide hook to generate meter GET (MeterReading)
SoapUI Project File:
MeterOnDemand MDMS-5.xml
Tag:
OD_MDM-CIS_Get(MeterReadings)
Endpoint:
http://baseurl:8080/epriConnect/ondemand/mdms/cis/requestGet2
WSDL:
GetMeterReadings
Request WSDL:
GetMeterReadings
SoapUI Mock Service:
MockService 1
SoapUI Request:
GetMeterReadings_Binding TestSuite
GeMeterReadings TestCase
Test Steps
GetMeterReadings
6. MDMS sends REPLY(#8 MeterReading)
SoapUI Project File:
MeterOnDemand MDMS-6.xml
Tag:
OD_MDM-CIS_Reply(6MeterReadings)
Endpoint:
http://baseurl:8080/epriConnect/
ondemand/mdms/ami/reply2
WSDL:
ReplyMeterReadings
SoapUI:
ReplyMeterReadings_Binding TestSuite
ReplyMeterReadings TestCase
Test Steps
Success
Fail

B-32

AMI
1. Provide hook to generate meter GET (MeterReading)
SoapUI Project File:
MeterOnDemand AMI-1.xml
Tag:
OD_AMI-MDM_Get(MeterReadings)
Endpoint:
http://baseurl:8080/epriConnect/ondemand/ami/mdms/requestGet
WSDL:
GetMeterReadings
Request WSDL:
GetMeterReadings
SoapUI Mock Service:
GetMeterReadings_Binding MockService
SoapUI Request:
GetMeterReadings_Binding TestSuite
GeMeterReadings TestCase
Test Steps
GetMeterReadings
2. AMI sends REPLY(#4 MeterReading)
SoapUI Project File:
MeterOnDemand AMI-2.xml
Tag:
OD_AMI-MDM_Reply(MeterReading)
Endpoint:
http://baseurl:8080/epriConnect/
ondemand/ami/mdms/reply
WSDL:
ReplyMeterReadings
SoapUI:
ReplyMeterReadings_Binding TestSuite
ReplyMeterReadings TestCase
Test Steps
Success
Fail
3. Provide hook to generate meter GET (MeterReading)
SoapUI Project File:
MeterOnDemand AMI-3.xml
Tag:
OD_AMI-CIS_Get(MeterReading)
Endpoint:
http://baseurl:8080/epriConnect/ondemand/ami/cis/requestGet
WSDL:
GetMeterReadings
Request WSDL:
GetMeterReadings
SoapUI Mock Service:
GetMeterReadings_Binding MockService
SoapUI Request:
GetMeterReadings_Binding TestSuite
GeMeterReadings TestCase
Test Steps
GetMeterReadings
B-33

4. AMI sends REPLY(#6 MeterReading)

SoapUI Project File:
MeterOnDemand AMI-4.xml
Tag:
OD_AMI-CIS_Reply(MeterReading)
Endpoint:
http://baseurl:8080/epriConnect/ondemand/ami/cis/reply
WSDL:
ReplyMeterReadings
SoapUI:
ReplyMeterReadings_Binding TestSuite
ReplyMeterReadings TestCase
Test Steps
Success
Fail

Meter Scheduled Package

Each test package contains a simplified description of the services and soapUI
project names for each interface. Follow the instructions above to change
endpoints/reply address as appropriate for each.

Figure B-33
Meter Scheduled package, UML diagram

B-34

AMI
1. Provide hook to generate CREATE(#1 MeterReadSchedule)
SoapUI Project File:
MeterSchedule MDMS-1.xml
Tag:
MS_AMI-MDM_Create(MeterReadSchedule)
Endpoint:
http://baseurl:8080/epriConnect/schedule/ami/mdms/requestSend
WSDL:
SendMeterReadSchedule
Request WSDL:
SendMeterReadSchedule
SoapUI Mock Service:
SendMeterReadSchedule_Binding MockService
SoapUI Request:
SendMeterReadSchedule_Binding TestSuite
SendMeterReadSchedule TestCase
Test Steps
CreatedMeterReadSchedule
2. Verify that REPLY(#2,MeterReadSchedule) is correct
SoapUI Project File:
MeterSchedule AMI-2.xml
Tag:
MS_AMI-MDM_Reply(MeterReadSchedule)
Endpoint:
http://baseurl:8080/epriConnect/
schedule/ami/mdms/reply
WSDL:
ReplyMeterReadSchedule
SoapUI:
ReplyMeterReadSchedule_Binding TestSuite
CreatedMeterReadSchedule TestCase
Test Steps
Success
Fail
3. Verify that CREATED(#3,MeterReading) is correct
SoapUI Project File:
MeterSchedule AMI-3.xml
Tag:
MS_AMI-MDM_Created(MeterReading)
Endpoint:
http://baseurl:8080/epriConnect/
schedule/ami/mdms/send
WSDL:
SendMeterReadings
SoapUI:
SendMeterReadings_Binding TestSuite
CreatedMeterReadings TestCase
Test Steps
Success
Fail
B-35

MDMS
1. Verify that CREATED(#1,MeterReadSchedule) is correct
SoapUI Project File:
MeterSchedule MDM-1.xml
Tag:
MS_MDM-AMI_Create(MeterReadSchedule)
Endpoint:
http://baseurl:8080/epriConnect/
schedule/mdms/ami/send
WSDL:
SendMeterReadings
SoapUI:
SendMeterReadSchedule_Binding TestSuite
CreatedMeterReadSchedule TestCase
Test Steps
Success
Fail
2. Provide hook to send REPLY(#2 MeterReadSchedule)
SoapUI Project File:
MeterSchedule MDMS-2.xml
Tag:
MS_MDMAMI_Reply(MeterReadSchedule)Endpoint:
WSDL:
ReplyMeterReadSchedule
Request WSDL:
ReplyMeterReadSchedule
SoapUI Mock Service:
ReplyMeterReadSchedule_Binding MockService
SoapUI Request:
ReplyMeterReadSchedule_Binding TestSuite
ReplyMeterReadSchedule TestCase
Test Steps
CreatedMeterReadSchedule
3. Provide hook to send CREATED(#3 MeterReading)
SoapUI Project File:
MeterSchedule MDMS-3.xml
Tag:
MS_MDM-AMI_Created(MeterReading)
Endpoint:
http://baseurl:8080/epriConnect/schedule/mdms/ami/request
WSDL:
SendMeterReadings
Request WSDL:
RequestMeterReadings
SoapUI Mock Service:
SendMeterReadings_Binding MockService
SoapUI Request:
RequestMeterReadings_Binding TestSuite
CreateMeterReadSings TestCase
Test Steps
CreateMeterReadings
B-36

Meter Tamper Package

Each test package contains a simplified description of the services and soapUI
project names for each interface. Follow the instructions above to change
endpoints/reply address as appropriate for each.

Figure B-34
Meter Tamper package, UML diagram

AMI
1. AMI sends CREATED(#1,EndDeviceEvents)
SoapUI Project File:
MeterTamper AMI-1.xml
Tag:
MT_AMI-MDM_Create(EndDeviceEvents)
Endpoint:
http://baseurl:8080/epriConnect/tamper/ami/mdms/send
WSDL:
SendEndDeviceEvents
SoapUI:
SendEndDeviceEvents_Binding TestSuite/
CreatedEndDeviceEvents TestCase/
Test Steps/
Success
Fail

B-37

MDMS
1. Provide hook to send CREATED(#1EndDeviceEvents)
SoapUI Project File:
MeterTamper MDMS-1.xml
Tag:
MT_MDM-AMI_Request_Created(EndDeviceEvents)
Endpoint:
http://baseurl:8080/epriConnect
/tamper/mdms/ami/requestCreate
WSDL:
SendEndDeviceEvents
Request WSDL:
SendEndDeviceEvents
SoapUI Mock Service:
SendEndDeviceEventsRequest_Binding MockService
SoapUI request:
SendEndDeviceEventsRequests_Binding TestSuite/
CreateEndDeviceEventsRequests TestCase/
Test Steps/
CreateEndDeviceEvents
2. Verify that CREATED(#2,EndDeviceEvents) is correct
SoapUI Project File:
MeterTamper MDMS-2.xml
Tag:
MT_MDM-AMI_Create(EndDeviceEvents)
Endpoint:
http://baseurl:8080/epriConnect/tamper/mdms/cis/send
WSDL:
SendEndDeviceEvents
SoapUI:
SendEndDeviceEvents_Binding TestSuite/
CreatedEndDeviceEvents TestCase/
Test Steps/
Success
Fail
CIS
1. Provide hook to send CREATED(#1EndDeviceEvents)
SoapUI Project File:
MeterTamper CIS-1.xml
Tag:
MT_CISMDM_Request_Created(EndDeviceEvents)
Endpoint:
http://baseurl:8080/epriConnect
/tamper/cis/mdms/requestCreate
WSDL:
SendEndDeviceEvents
Request WSDL:
SendEndDeviceEvents
SoapUI Mock Service:
SendEndDeviceEvents_Binding MockService
SoapUI Request:
SendEndDeviceEvents_Binding TestSuite
CreatedEndDeviceEvents TestCase
Test Steps
CreateEndDeviceEvents
B-38

Meter Outage Package

Each test package contains a simplified description of the services and soapUI
project names for each interface. Follow the instructions above to change
endpoints/reply address as appropriate for each.

Figure B-35
Meter Outage package, UML diagram

OMS
1. Provide hook to send CREATED(#2 EndDeviceEvents)
SoapUI Project File:
MeterOutage OMS-1.xml
Tag:
MO_OMS-MDM_Created(EndDeviceEvents)
Endpoint:
http://baseurl:8080/epriConnect/outage/oms/mdm/requestSendEndDev
iceEvents
WSDL:
SendDeviceEvents
Request WSDL:
SendDeviceEvents
SoapUI Mock Service:
SendEndDeviceEvents_Binding MockService
SoapUI Request:
SendEndDeviceEvents_Binding TestSuite
CreatedEndDeviceEvents TestCase
Test Steps
CreatedEndDeviceEvents

B-39

MDMS
1. MDMS sends CREATED(#2,EndDeviceEvents)
SoapUI Project File:
MeterOutage MDMS-1.xml
Tag:
MO_MDM-OMS_Created(EndDeviceEvents)
Endpoint:
http://baseurl:8080/epriConnect/
outage/mdms/ami/send
WSDL:
SendEndDeviceEvents
SoapUI:
SendEndDeviceEvents_Binding TestSuite/
CreatedEndDeviceEvents TestCase/
Test Steps/
Success
Fail
Port Forwarding
When requesting the test harness to send a message to a receiving application, a
reply address (and port) must be supplied in the request message. This address
must be known to the cloud instance, either in the form of a qualified DNS
name, or an IP address. This can be problematic when testing from either a
laptop or development server, which may not have an external IP/public
hostname.
If this is the case, then port-forwarding should solve the problem. Contact your
system administrator for further assistance.
If testing from a home network, most routers have the capability to port forward.
Determine the routers IP address (usually from the status page) and use that as
the reply address.

B-40

Appendix C: Creating XSD files

The following step-by-step process was used to create new XSD files to support
Part 9 testing.
1) Create a working folder. Locate EndDeviceEvents.xsd (now in
http://iectc57.ucaiug.org/WG14/Part9/Shared%20Documents/Part%209%202
Ed/61968-9%20-%202nd%20Edition%20Profiles%20-%2008-12-2011.zip );
Locate Message.xsd (in
http://iectc57.ucaiug.org/WG14/part100/Shared%20Documents/Common%20
Message/Message.xsd ); save copies of these to the new folder.
2) Create EndDeviceEventsMessage.xsd by editing
61968_1_2_Message_Templatev6.xsd (in
http://iectc57.ucaiug.org/WG14/part100/Shared%20Documents/WSDL%20
Generation/61968_1_2_Message_Templatev6.xsd ) and replacing
"{Information_Object_Name}" with "EndDeviceEvents" and saving file in the
new folder as EndDeviceEvenetsMessage.xsd.
3) Using Altova XMLSpy, open EndDeviceEventsMessage.xsd,
Request XMLSpy "Generate Sample XML File... selecting root element
"CreatedEndDeviceEvents"
4) For each element in the message, either delete it or add content. Save file to
the new folder.
a) For example, the sample file from XMLSpy chooses the first enumeration
of <msg:Verb> of "cancel" but I know that "created" is more appropriate
for this message. XMLSpy guides the user to pick only appropriate items
from enumerations (that is one reason to convert "string" to
"enumerations" for verbs and nouns.
b) <msg:Revision> is not appropriate for this message, so the element was
deleted. Immediately after deletion, a validation test should be executed
and the element re-inserted upon a validation error (because failures
indicate removal of mandatory items). In many case, I skipped the
validation step where "I knew what I was doing"
c) <msg:MessageID> is needed and a "reasonable" string value was handgenerated. In most cases, there is no validation on the string contents so
XMLSpy "validate" step is not needed

C-1

5) Save the file as CreatedEndDeviceEvents_Sample_Outage_2p05.xml

6) (optional step) Create the minimum and maximum files with the absolute:
a) minimum requirement for the message producer that a message consumer
could make sense of
b) maximum allowable content in a produced message that a message
consumer is required to be able to parse (consumer could discard
information, but it could not reject that information)
Note: Stylus Studio could also be used as it has much the same capabilities,
However Stylus Studio does not provide a drop-down list of valid entries
while editing the text. Otherwise the XMLSpy and Stylus Studio
products have similar functionality.

C-2

Appendix D: Glossary
AMI-

Automatic Metering Infrastructure

AWS-

Amazon Web Services

CIM-

Common Information Model

COTS-

Commercial off the shelf software

DMS-

Distribution Management System

MDMS-

Meter Data Management

DNS-

Domain Name Service

EC2-

Amazon Elastic Compute Cloud

OMS-

Outage Management System

PUTTYA-

common Windows implementation of SSH

SSH-

Secure Shell

D-1

The Electric Power Research Institute Inc., (EPRI, www.epri.com)

conducts research and development relating to the generation, delivery
and use of electricity for the benefit of the public. An independent,
nonprofit organization, EPRI brings together its scientists and engineers
as well as experts from academia and industry to help address challenges
in electricity, including reliability, efficiency, health, safety and the
environment. EPRI also provides technology, policy and economic
analyses to drive long-range research and development planning, and
supports research in emerging technologies. EPRIs members represent
more than 90 percent of the electricity generated and delivered in the
United States, and international participation extends to 40 countries.
EPRIs principal offices and laboratories are located in Palo Alto, Calif.;
Charlotte, N.C.; Knoxville, Tenn.; and Lenox, Mass.
Together...Shaping the Future of Electricity

Program:
IntelliGrid

2011 Electric Power Research Institute (EPRI), Inc. All rights reserved. Electric Power
Research Institute, EPRI, and TOGETHER...SHAPING THE FUTURE OF ELECTRICITY are
registered service marks of the Electric Power Research Institute, Inc.

1024448

Electric Power Research Institute

3420 Hillview Avenue, Palo Alto, California 94304-1338PO Box 10412, Palo Alto, California 94303-0813 USA
800.313.3774 650.855.2121askepri@epri.comwww.epri.com