Lrs External Web Services Specifications PDF

July 9th, 2009

Version: 1.4

PJM LRS

External Web Services

Design Specification

REVISION RECORD

Date Version Description Author(s)

LRS – External Web-Services Design

Confidential and Proprietary

CONTENTS

1 INTRODUCTION .......................................................................... 6

1.1 PURPOSE ................................................................................................................. 6

1.2 SCOPE ..................................................................................................................... 6

1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS ................................................... 7

1.4 REFERENCES ........................................................................................................... 9

1.5 OVERVIEW .............................................................................................................. 9

1.6 PROGRAM-LEVEL STANDARDS ................................................................................ 9

2 SERVICES ORGANIZATION ..................................................... 11

2.1 COMMON MESSAGE STRUCTURE .......................................................................... 11

2.1.1 Message Header Structure ............................................................................ 11

2.1.2 Request Message Structures ......................................................................... 13

2.1.3 Payload Structures ........................................................................................ 14

2.1.4 Response Message Structures ....................................................................... 16

2.2 COMMON SECURITY IMPLEMENTATION ................................................................ 17

2.2.1 Secure the Transport layer............................................................................ 17

2.2.2 Application Level Authentication .................................................................. 18

2.3 MODELING AND CONVENTIONS ............................................................................ 19

2.3.1 Use of the IEC CIM....................................................................................... 19

2.3.2 Representation of Time ................................................................................. 20

2.3.3 Other Conventions ........................................................................................ 21

2.4 DELIVERY APPROACH ........................................................................................... 21

2.5 TECHNICAL INTEROPERABILITY ............................................................................ 22

2.6 SERVICE LEVEL AGREEMENTS .............................................................................. 23

2.7 AUDITING, MONITORING AND MANAGEMENT ...................................................... 23

2.8 VERSIONING .......................................................................................................... 23

2.9 GOVERNANCE ....................................................................................................... 24

2.10 WEB SERVICE CONFIGURATION STANDARDS ...................................................... 24

3 LOAD RESPONSE OBJECTS .................................................. 25

3.1 LOCATION ............................................................................................................. 25

3.1.1 Location Fields ............................................................................................. 25

3.1.2 Location Diagram ......................................................................................... 27

3.1.3 Location XML Example ................................................................................ 27

3.2 REGISTRATION ...................................................................................................... 28

3.2.1 Registration Fields ........................................................................................ 28

3.2.2 Registration Diagram ................................................................................... 30

3.2.3 Registration XML Example ........................................................................... 30

3.3 EVENT ................................................................................................................... 32

3.3.1 Event Fields .................................................................................................. 32

3.3.2 Event Diagram .............................................................................................. 33

3.3.3 Event XML Example ..................................................................................... 33

3.4 SETTLEMENT ......................................................................................................... 33

3.4.1 Settlement Fields ........................................................................................... 34



3.4.2 Settlement Diagram ...................................................................................... 35

3.4.3 Settlement XML Example .............................................................................. 35

3.5 PROCESS ............................................................................................................... 36

3.5.1 Process Fields ............................................................................................... 36

3.5.2 Process Diagram .......................................................................................... 38

3.5.3 Process XML Example .................................................................................. 38

3.6 DAILY DATA ......................................................................................................... 39

3.6.1 Daily Data Fields .......................................................................................... 39

3.6.2 Daily Data Diagram ..................................................................................... 39

3.6.3 Daily Data XML Example ............................................................................. 39

3.7 INTERVAL DATA ................................................................................................... 40

3.7.1 Interval Data Fields ...................................................................................... 40

3.7.2 Interval Data Diagram ................................................................................. 40

3.7.3 Interval Data XML Example ......................................................................... 41

3.8 ALERT DATA......................................................................................................... 41

3.8.1 Alert Data Fields........................................................................................... 41

3.8.2 Alert Data Diagram ...................................................................................... 42

3.8.3 Interval Data XML Example ......................................................................... 42

4 LOAD RESPONSE INFORMATION .......................................... 43

4.1 INTERFACES PROVIDED ......................................................................................... 43

4.2 INTERFACES REQUIRED ......................................................................................... 44

4.3 MESSAGE SPECIFICATIONS .................................................................................... 45

4.3.1 Location ........................................................................................................ 45

4.3.2 Registration ................................................................................................... 46

4.3.3 Event ............................................................................................................. 47

4.3.4 Alert............................................................................................................... 48

4.3.5 Settlement ...................................................................................................... 49

4.3.1 Process .......................................................................................................... 50

4.3.2 Measurement Data ........................................................................................ 51

5 LOAD RESPONSE TRANSACTIONS ....................................... 54

5.1 INTERFACES PROVIDED ......................................................................................... 54

5.2 INTERFACES REQUIRED ......................................................................................... 55

5.3 MESSAGE SPECIFICATIONS .................................................................................... 57

5.3.1 Location ........................................................................................................ 57

5.3.2 Registration ................................................................................................... 59

1.3.2 Event ............................................................................................................. 62

1.3.3 Settlement ...................................................................................................... 62

1.6.2 Process .......................................................................................................... 65

1.6.3 Measurement Data ........................................................................................ 66

APPENDIX A: WSDL FOR DR REQUESTS ................................... 68

APPENDIX B: XML SCHEMAS ...................................................... 71

APPENDIX C: PAYLOAD COMPRESSION EXAMPLE ................. 88



FIGURES

Figure 1 - Message Header Structure ........................................................................... 12

Figure 3 - Request Message Structure .......................................................................... 13 Figure 3 - Message Request Parameters ....................................................................... 14 Figure 4 - Message Payload Container Structure ........................................................ 15 Figure 5 - Response Message Structure ........................................................................ 16

Figure 6 – Example class diagram ................................................................................. 20 Figure 7 - LR Information Request Sequence Diagram .............................................. 43 Figure 8 - LR Transaction Request Sequence Diagram .............................................. 55



1 Introduction

This document describes the message structure for machine to machine interfaces for

Load Response (LR) Participant applications that need to interact with PJM

Interconnection Load Response System (LRS). The intended audience of this document

is developers that will be integrating PJM customers applications to the PJM

Interconnection Load Response Systems through the use of the interfaces described

within this specification.

Where sections 1 and 2 of this document apply to all interfaces, sections 3 and beyond

describe specific groupings of interfaces. The appendices provide XML Schemas,

WSDLs and additional examples.

The interfaces and related interactions described by this document define the externally-

visible (black box view) perspective of the services provided by this project. It is the

intent of this specification and interface architecture to shield PJM Customers from the

details of systems integration internal to PJM.

1.1 Purpose

The interfaces described by this document are intended to be used by PJM Clients for

machine to machine integration. This document is intended to provide all the details of

the message structures and technical interoperability standards required for the machine

to machine interface.

1.2 Scope

The scope of this document is to describe web services provided for integration by PJM

Customers from the perspective of external integration. This document has program level

scope as related to web services that would be used by PJM Customers for machine to

machine interaction with PJM Demand Response applications as detailed in an agreed list

of interfaces to be managed by the project. The intent of this design is to leverage the

integration layer (IL) to expose web services needed for external integration by PJM

Customers.

The following are specifically outside the scope of this document:

Interactions with application User Interfaces (UI)

Reports that might utilize the web-services framework

Asynchronous web-services notifications or alerts

Valid runtime data codes (zones, weather stations, organization names, etc)

Business rules regarding read/write privileges for objects, organizations and users



1.3 Definitions, Acronyms, and Abbreviations

Term or

Acronym

Definition

AC2 Advanced Control Center, a PJM initiative

AJAX Asynchronous Javascript and XML

Alert A message sent to a user to indicate a condition where action may be

required, commonly communicated using e-mail

API Application Programming Interface

AS Ancillary service market

BPM Business Process Management, where Savvion is the BPM engine used

within DRBizNet for the management of potentially long running,

multi-user workflows

CBL Customer base load

CSP Curtailment Service Provider

CSV Comma separated value format

DA Day ahead market

DDL Database Definition Language, used to define relational database

schemas

DLC Direct load control

DMZ De-Militarized Zone, a network partition

DR Demand response

DSR Demand side response

EDC Electric Distribution Company

eMkt Short form of eMarket, the PJM Markets Management System

ESB Enterprise Service Bus, used for the implementation of AC2

eSuite PJM web-based user interface for market participants

Event An invocation of a DR program on a given day for a defined time

period

HE Hour ending, a value typically in the range 1-24

HTTP Hyper-Text Transfer Protocol, and IETF standard

HTTP/S HTTP using secured sockets

IETF Internet Engineering Task Force

ISO Independent System Operator

JDBC Java Database Connectivity

LDAP Lightweight Directory Access Protocol

LMP Locational marginal price, usually identified at a PNode

LSE Load Serving Entity

Location A place that can be metered and registered for participation in a DR

program

LRS Load Response System, which will be re-implemented using DRBizNet

MSET PJM Market Settlement System

MSRS New database for PJM Market Settlement System



NERC National Energy Regulatory Commission

Orchestration Within DRBizNet TIBCO is used for the orchestration of service,

periodic and integration processes

PJM An ISO

PNode Pricing node

Program Demand response program, can be defined using emergency or

economic rules

RBAC Role-based access control

RDBMS Relational database management system, e.g. Oracle

Registration The process by which a customer location is registered for a specific

DR program

RPM Reliability Pricing Model

RSS Remote Syndication Service

RT Real-time market

SAA Symmetric additive adjustment, a method for calculating CBLs

Self Schedule

Settlement A document that is generated as the result of an event that provides the

information required to initiate payment processing, including the

amount that is owed

SMS Short Messaging System, used for short text messages to cell phones

SMTP Simple Mail Transfer Protocol, an IETF standard used for e-mail

SOA Service-Oriented Architecture

SOAP Simple object access protocol, based upon XML

SP Stored Procedure, where capabilities and syntax are specific to a

database product

SQL Structured Query Language, as defined as an ANSI standard and often

extended by database products

UDS PJM Unit Dispatch System

UML Unified Modeling Language

VOIP Voice over IP, within the context of LRS requirements the intent is to

provide an interface to a telephony infrastructure

W3C Worldwide Web Consortium

WS Web Services

WS-* Used to designate web services standards defined by the W3C

WS-I WS-I Basic Profile 1.0 –

http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html

WSA Weather sensitive adjustment, a method for calculating CBLs

WSDL Web Services Definition Language

XML Extensible Markup Language

XSD XML Schema, used to define the structure of XML documents

XSL XML Stylesheet Language, used to transform XML documents

http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html



1.4 References

Artifact Definition

External Interfaces

Security Design

Specification

Detailed security design for external interfaces. This is a companion document to the External Interfaces Conceptual

design.

XSDs Specific message structure and element details.

Additional references to related standards are described in section 1.6.

1.5 Overview

This document focuses on the external interface design and related interface definitions

from all perspectives except for security, which is described in detail in a companion

document. The interfaces are to be provided using web services, where a rationale is

provided in subsequent sections.

1.6 Program-level Standards

In general, the design described by this document will leverage web services and related

security standards as defined by the World-Wide Web Consortium (W3C) and OASIS.

Program-level standards include those related to security, as well as basic web service

standards including:

XML

XML Schema

XPath

XSL

SOAP

Web Services

WSDL

These are described in the companion security design document. W3C standards can be

freely accessed from http://www.w3.org.

Another key program standard is the IEC Common Information Model (CIM), as defined

by IEC 61970-301. This is used to define models used by PJM, which are exchanged

using IEC 61970-501. It will also be leveraged by this design for the definition of

messages used for interfaces. There is also a standard for message structures defined by

IEC 61968-1. There standards can be purchased from the IEC web site at

http://www.iec.ch. Materials related to IEC standards, including the CIM model it self

http://www.w3.org/

http://www.iec.ch/



can be freely obtained from the UCA International Users Group SharePoint at

http://sharepoint.ucausers.group.org/CIM.

There are several key Internet Engineering Task Force references. These include:

Internet Engineering Task Force RFC 2828: Internet Security Glossary

Internet Engineering Task Force RFC 2119: Key words to indicate RFC

requirement levels

Internet Engineering Task Force RFC 2246: Transport Layer Security (TLS)

Internet Engineering Task Force RFC 3275: XML Digital Signature and

Processing

IETF documents can be freely obtained from http://www.ietf.org.

OASIS standards can be freely obtained from http://www.oasis-open.org.

The definition of timestamps is specified by ISO-8601, with the exception that

timestamps of 24:00:00 are not used for compatibility reasons. This is partly a

consequence of the XML Schema definition for ‘dateTime’, where hour 24 is not

explicitly allowed. There are some implementations of timestamps within software

products that do not correctly handle timestamps of 24:00:00.

ISO standards can be purchased online from a variety of sources including ANSI, at

http://www.ansi.org. Descriptions of ISO-8601 can be freely obtained from other sources

including Wikipedia.

http://sharepoint.ucausers.group.org/CIM

http://www.ietf.org/

http://www.oasis-open.org/

http://www.ansi.org/



2 Services Organization The services described by this document are defined using a combination of Web

Services Definition Language (WSDL) and XML Schema. The WSDLs are organized as

follows:

One or more WSDLs defined by PJM, defining operations related to synchronous

request/reply web service messages

In both of the above cases, one or more XML Schemas (XSD) is used to define the

structure of message payloads.

Throughout this document there are diagrams representing XSD structures.

Understanding the diagrams will assist in implementing any services based on these

XSDs. Below is a link which elaborates the details and structures of the XSD diagrams.

http://www.diversitycampus.net/Projects/TDWG-

SDD/Minutes/SchemaDocu/SchemaDesignElements.html

Example WSDL and XSD are provided in the appendices. It is anticipated that these

would be key design artifacts for developers.

2.1 Common Message Structure

Unless otherwise specified, all messages use a common message envelope, where a

predefined structure is used for requests and another structure is used for responses.

This structure is based upon the IEC 61968-1 standard. Messages are constructed

with several sections, including:

Header: required for all messages, using a common structure for all service

interfaces

Request: optional, defining parameters needed to qualify request messages

Reply: Used for response messages to indicate success, failure and error

details

Payload: optional, used to convey message information as a consequence of

the ‘verb’ and ‘noun’ in the message Header. The payload structure provides

options for payload compression.

2.1.1 Message Header Structure

Common to both the request and response messages is a header structure. The header

has several required fields that must be populated, these include:

Verb, to identify a specific action to be taken. There are an enumerated set of

valid verbs, where commonly used values include

http://www.diversitycampus.net/Projects/TDWG-SDD/Minutes/SchemaDocu/SchemaDesignElements.html

http://www.diversitycampus.net/Projects/TDWG-SDD/Minutes/SchemaDocu/SchemaDesignElements.html



o ‘get’, ‘create’, ‘change’, ‘action’, ‘cancel’, ‘close’ and ‘reply’.

Implementations treats verbs ‘update’ and ‘updated’ as synonyms to ‘change’

and ‘changed’.

Noun: to identify the subject of the action and/or the type of the payload (e.g.

Registration, Notification) if a payload is provided.

Revision: To indicate the revision of the message definition.

Source: identifying the source of the message which should be the ID of the

DR Participant or PJM (typically for reply messages). This should be the

‘short name’ of the submitter.

UserID: Should be supplied as it may be required for some interfaces,

depending upon underlying implementations.

MessageID: If populated on a request, it will be returned on the reply.

Comment: It is never used for any processing-related logic.

The following diagram describes the header structure used for request and response

messages.

Figure 1 - Message Header Structure



There are several optional fields that may be populated. In the above diagram, the

optional items are represented using dashed borders. If the MessageID is populated

on a request, it will be returned on the reply. The Comment field is never used for any

processing-related logic. The UserID may be used to indicate the person responsible

for initiating a transaction, and will be logged as appropriate, but verification is the

responsibility of the Source system.

In order to identify the DR Participant in a uniform manner, the registered ‘short

name’ of the DR Participant should be supplied as the value of Header/Source. PJM

will verify that this value is consistent with the DR Participant as identified by the

certificate, noting the DUNS number is contained within the certificate.

2.1.2 Request Message Structures

The following diagram describes the structure of a request message that would be

used in conjunction with a WSDL operation.

Figure 2 - Request Message Structure

The RequestMessage can also optionally contain a package with parameters relevant

to the request, called Request. It is likely that different or variant Request packages

may be defined to be used in conjunction with messages for a specific web service

operation. In those cases, the corresponding WSDL and XSD would identify the

optional parameters. The description of the interface (in subsequent sections of this

document) would identify the usage of those parameters. The following is an example

RequestType used in the definition of a Request package that defines some common

parameters used for requests, however it is important to note that these are typically



application specific. These parameters are most commonly used in conjunction with

‘get’ requests as qualifiers.

Figure 3 - Message Request Parameters

One key use of the RequestType is to avoid the placement of application specific

request parameters in the header or within payload definitions. Also, where a set of

requests that were supported by a specific web service operation had significantly

different requirements for information in the RequestType, it could justify the use of

RequestType variants, where each variant will be used for the definition of messages

for the specific web service operation.

2.1.3 Payload Structures

There are some requests where a Payload must be provided, as would be the case for

a message with a verb of ‘create’ or ‘change’. Payloads are typically XML documents



that conform to a defined XML schema. There may be cases where a large payload

must be compressed, in the event that it would become very large and otherwise

consume significant network bandwidth. In order to accommodate a variety of

payload format options the following payload structure is used.

Figure 4 - Message Payload Container Structure

In the previous diagram, any type of XML document may be included, using the

XML ‘any’ structure. While this provides options for loose-coupling, specific

complex types defined by XML schemas (XSDs) can be used as well. The WSDL in

the appendix provides an example of this case.

Payloads can also be supplied as XML encoded strings using the ‘Document’ tag,

although this method is less preferred than used of the XML ‘any’.

There are also some cases where a zipped, base64 encoded string is necessary, and

would be passed using the ‘Compressed’ tag. The Gnu Zip compression shall be used

in order to provide compatibility within both Java and Microsoft .Net

implementations. A Java example is provided in Appendix G. Specific examples of

the usage of payload compression would be where:

1. An XML payload, conforming to a recognized XML schema exceeds a

predefined size (e.g. 1MB). This would be very common for large DR

Participant sets of bids, offers, trades or schedules

2. A payload has a non-XML format, such as PDF, Excel spreadsheet, CSV file

or binary image

3. A payload is XML, but has no XML schema and exceeds a predefined size, as

would be the case of a dynamic query that would return an XML result set

When a payload is compressed and base64 encoded, it is stored within the

Payload/Compressed message element as a string.

The format tag can be used to identify specific data formats, such as XML, RDF,

PDF, DOC, CSV, etc. This is especially useful if the payload is compressed. The use



of this tag is optional, and would typically only be used when the payload is stored

using the Payload/Compressed message element.

The above options provide an alternative to the use of SOAP attachments. SOAP

attachments are more difficult to secure since the SOAP envelope signature signs the

SOAP body but does not sign the attachment. This also requires that the payload is

processed separately from the rest of the SOAP message (e.g. the message is parsed

to extract the payload, and then the payload is parsed and processed). However, we

believe this implementation approach is less complex than using SOAP attachments.

2.1.4 Response Message Structures

The following diagram describes the structure of a response message that would be

used in conjunction with a WSDL operation, as a response to the request message.

Figure 5 - Response Message Structure



The ReplyCode would be set to ‘ok’ to indicate that the request was successful, otherwise it

would be set to either ‘fatal’ or ’warning’, and one or more Error elements would be provided

to describe the error(s). ‘fatal’ ReplyCode is indicative of an internal error having occurred.

‘warning’ ReplyCode is indicative of an empty result set due to an invalid identifier or a

search returning no data.

The Error message will contain a text string beginning with a 4 digit error code corresponding

to the type of error. At present, these include –

4001 - Unable to process the request {catch-all}

4002 – Authorization error

4003 – Verb-noun combination missing or unknown

4004 – Request-payload missing or unknown

4005 – Parameter missing

4006 – Invalid parameter

4007 – Data validation errors

4008 – Requested ID not found

4009 – Search returns no data

There may also be more specific error information provided within the payload, as in the case

of registration within a Registration container.

If the MessageID was set in the Header for the RequestMessage, the value will be returned in

the Header of the ResponseMessage.

2.2 Common Security Implementation

This section will provide an overview of security from the perspective of

implementation requirements for PJM Customers. PJM Customers MUST take two

basic steps in securing their Web Services Interaction with PJM:

1. Secure the Transport layer

2. Application level Authentication

2.2.1 Secure the Transport layer

The transport layer is secured by deploying Secure Socket Layer (SSL) and Transport

Layer Security (TLS) following these steps:

1. PJM will Implement Server Side Authentication (explained below).

2. PJM will Ensure minimum SSL/TLS security settings



Note that TLS is an enhanced specification based on SSL. References to SSL refer to

both SSL and TLS.

SSL is a standard mechanism for Web services that is available on virtually all

application servers. This widely used, mature technology, which secures the

communication channel between client and server, will satisfy all of PJM’s use cases

for secure Web Service communications. Since it works at the transport layer, SSL

covers all information passed in the channel as part of a message exchange between a

client and a server, including attachments. Authentication is an important aspect of

establishing an HTTPS connection. Many platforms support the following

authentication mechanisms for Web Services using HTTPS:

The PJM BigIP server (DMZ resident Proxy Server) authenticates itself (via

F5 appliance) to web services clients with SSL and makes its certificate

available (one way web server authentication).

With Web Services, the interaction use case is usually machine to machine; that is, it

is an interaction between two application components with no human involvement.

Machine-to-machine interactions have a different trust model from typical website

interactions. In a machine-to-machine interaction, trust must be established

proactively, since there can be no real-time interaction with a user about whether to

trust a certificate. Ordinarily, when a user interacts with a website via a browser and

the browser does not have the certificate for the site, the user is prompted about

whether to trust the certificate. The user can accept or reject the certificate at that

moment. With Web Services, the individuals involved in the deployment of the Web

Service interaction must distribute the server certificate prior to the interaction

occurrence.

2.2.2 Application Level Authentication

Besides creating a secure communication channel between a client and a Web

Service, PJM Web Service message exchanges require that authentication information

(username and password) be embedded within the SOAP message header.

Application level authentication is done through the following:

Include username and password in the SOAP header.

The Tibco integration layer will perform the initial username/password authentication

against PJM Open_LDAP and it will pass on the authenticated user role information

to the LRS application for authorization validation purposes.

Appendix E provides an annotated example of a SOAP message.



2.3 Modeling and Conventions

There are several conventions that are used for definitions, data items and information

models. Note that additional values and conventions will be defined as DR

requirements are finalized.

2.3.1 Use of the IEC CIM

Where possible the IEC CIM should be leveraged. The PJM Interconnection project

and related systems use the CIM as a key standard. Examples of leveraging the CIM

for external web services include:

The use of data structures defined by the IEC CIM where appropriate in

payload definitions

CIM naming conventions are used wherever possible, e.g. ClassName,

propertyName

The properties ‘startTime’ and ‘endTime’ are typically used to identify time

intervals, as they are also used within many CIM classes. Instead of using

combinations of start date, start hour and potentially an interval number (e.g.

to represent 15 minute intervals), absolute times should be specified.

The following class diagram describes the structure of CIM Curves,

IrregularIntervalSchedules and RegularIntervalSchedules. These classes are CIM

building blocks, where there are many other classes in the CIM that inherit from these

three basic types of curves and schedules (e.g. PriceCurve).



Figure 6 – Example class diagram

2.3.2 Representation of Time

The ISO 8601 standard is used to define the representations of time values that are

conveyed through interfaces. This avoids issues related to time zones and daylight

savings time changes.

For timestamps in messages published by PJM would use Eastern prevailing

time, using the following format: 2007-03-27T14:00:00-05:00 (as time

changes from EDT to EST, the -05:00 would change to -06:00)

Timestamps in messages sent to PJM by PJM Customers could use any ISO

8601 compliant timestamp (with the exception of 24:00, as described in

section 1.6)

It is extremely important to note that the use of ISO 8601 timestamps within message

definitions for the external interfaces defined by this document in no way constrains

other representations of time that may include:

User interfaces, where local time or DR hours may be used as desired

Reports, where reports would be generated using an appropriate local time



Internal integration, where an application may internally require some other

time structure

In some cases it may be desirable to convert between a timestamp and a local time or

a DR hour. This can be readily accomplished using software functions, XSL and/or

XPath expressions. Examples of time conversion using XSL are provided in

Appendix F. Most development environments have a wide variety of APIs that can

also be used for necessary time conversions.

In cases where there are a sequence of startTime and endTime intervals provided (as

in the cases of ResourceStatus or MinimumEnergy structures as examples),

overlapping time intervals are not allowed and will be flagged as an error. Typically

in these cases the endTime for one interval should identically match the startTime for

the next interval.

In cases where a time that is ‘aligned’ with an interval is expected, but not provided

on a request message (e.g. 2008-01-01T01:03:23-06:00), the integration layer may

round the time to the nearest minute. This may result in an error being generated by

the target application if the minute is not a valid interval boundary. In cases where a

time that is aligned with an hour boundary is expected, but not provided on a request

message, the integration layer may round the time to the nearest hour. In this case,

there may be no generation of an error message.

2.3.3 Other Conventions

The following are other conventions that must be followed by this specification:

Within XML definitions, tags should be namespace qualified. For example, a

tag of <tag> should be prefixed by a specific namespace reference, e.g.

<ns:tag>. This will help to eliminate ambiguity. (Note that many examples in

this document are not namespace qualified for brevity and to aid legibility)

Units for power quantities are in kilowatts (KW).

Units for capacity quantities are in kilowatts (KW).

Units for energy quantities are in kilowatt-hours (KWh).

Units for energy prices are in $/KWh.

Trading dates are specified using YYYY-MM-DD, which indicates the

operating day

2.4 Delivery Approach



In advance of LRS go live and in accordance with agreed schedule and dependencies,

PJM will provide the following:

Interface specifications for web services

Design artifacts, including XML schemas and WSDLs

Source code examples for web service clients

The interface specifications, artifacts and implementation of the sand box

environment will be staged. An iterative implementation approach will be used,

where feedback from each stage will be used to plan subsequent stages.

2.5 Technical Interoperability

There are several strategies that can be employed in order to achieve technical

interoperability with PJM. These include:

Use of open standards

Working group that allows input from PJM Customers on interoperability

issues

The early deployment of a sandbox environment that enables PJM to work

with the PJM Customers to insure interoperability issues are addressed

prior to DR trials

Providing sample Java and .Net web service client code

Deployment of interfaces via the sandbox environment for early testing by

PJM Customers, so that feedback can be provided to PJM

Open standards are a key part of the strategy to achieve technical interoperability.

Standards of particular interest include:

W3C standards

OASIS WS-* standards

IEC Common Information Model and related standards (e.g. IEC 61968-1)

WS-I Basic Profile 1.0

It is very important that the implementation of Web Service interfaces not be

dependent upon any proprietary, third party products. Another key requirement is that

implementation of web service clients must be possible using both Java and .Net

development tools.

More details on technical interoperability will be provided as a consequence of

existing web services provided by PJM, detailed design and experience with the Sand

Box environment.



2.6 Service Level Agreements

Different categories of Web Services will have different service level agreements

(SLAs). The SLAs for some Web Services are directly impacted by the variability in

the amount of data that can be transferred (e.g. large payloads).

The response time periods specified for each interface covered by an SLA typically

will vary to some degree, based upon factors such as network and system loading.

Consequentially, each SLA will be stated in a manner such that each SLA will be

honored Z% of the time.

2.7 Auditing, Monitoring and Management

PJM will perform auditing, monitoring and management for Web Services described

by this specification using common services. Internal auditing by PJM will be used to

track and insure that SLAs are met by PJM. All Web Service requests will be logged

by PJM in order to permit calculations related to SLAs. The signatures supplied on

SOAP messages will be recorded with transactions as a means of non-repudiation of

each transaction.

It is important to recognize that PJM is not responsible for the monitoring and

management of DR Participant software and network connectivity. Therefore PJM

cannot guarantee that notification interfaces provided by PJM Customers are

accessible as needed for timely delivery of notifications.

2.8 Versioning

It is important to recognize that new versions of interfaces may be provided over

time, largely as a consequence of:

Staging of initial implementation

New requirements

Upgrades to vendor products

Wherever possible, interfaces will be evolved through augmentation, where a newer

version of an interface is compatible with a previous version of an interface.

However, this will not always be possible. New versions of interfaces will be

manifested by:

Changes to WSDLs

Changes to XML Schemas

Changes to software implementations



2.9 Governance

The web service interfaces will be critical to the operations of both PJM and PJM

Customers. The Web Services will evolve for many reasons, especially as the needs

of the DR evolve. Governance policies and processes will need to be defined for the

Web Service lifecycle that provide strict guidelines related to:

Design

Implementation

Testing

Deployment

Management

2.10 Web Service Configuration Standards

PJM will configure its web servers with specific parameters for use of Web Services

by PJM Customers (e.g. for security). PJM Customers will also need to set up Web

Services to handle notifications from PJM. PJM will define specific configuration

details and parameters to be used by PJM Customers.



3 Load Response Objects

This section describes the data objects used in web-services payloads by the PJM

Load Response system. Use of the fields is typically dependent on the type of

request. This is summarized on the right (1=provided/mandatory, 0=optional,

0|1..n=set, blank=ignored), and defined further in later sections of this document. All

fields are subject to PJM business rules regarding organization (and user) read/write

privileges for each object.

Note: The object and message specifications described in this section are subject to

change based upon final DRBizNet design.

3.1 Location

A Location object is used to describe a specific EDC account used as a resource in a

registration.

3.1.1 Location Fields

The following is a description of all the fields in a Location object.

Field Description Example get create change

ID Location object identifier 282718 1 1

Summary info 1 1 0

Name Descriptive name of location Walmart #2234 1 1 0

CSP Short name of the CSP PECO 1 1

EDC Short name of the EDC PGE 1 1

EDCAccount Account no. at the EDC 2672827273 1 1

Zone Short name of the zone PGE-WEST 1 1

Status Status of the location Active 1

Site info 1 1 0

Address1 Address line 1 273 Main St. 1 1

Address2 Address line 2 Suite 3400 1 0

City City Springfield 1 1

State Two-letter state code NY 1 1

Zip Code 5 or 9 number zip code 39482 1 1

Business Segment Business segment code School 1 1

Pnode Pnode identifier 27382 1 0

Profile info 1 1 0

Energy Loss Factor Decimal loss factor 1.003 1 1 0



Capacity Loss

Factor

Decimal loss factor 1.003

1 1 0

Retail Rate Decimal retail rate (c/kwh) 20.5 1 1 0

Total Load

Reduction

Decimal value of total load

reduction (kw)

2000

1

Peak Load

Contribution

Decimal value of peak load

contibution (kw)

2000

1 1

Load Multiplier An integer number of sites

(default is 1)

5

1 0 0

Generation Fuel

Type

Fuel type code OIL

1 0 0

Meter

Qualification Date

Date on which the meter was

qualified by PJM

12/1/2008

1

State Qualification

Date

Date on which state

qualification was received

1/1/2010

1

Reduction info 1..n 1..n 0..n

Reduction type Reduction type code HVAC 1 1 0

Reduction value Decimal number of kw of

reduction for this type

40.5

1 1 0

Meter Info 1 1 0

Meter Owner Meter owner code 1 1 1

Allow EDC to

submit data

Boolean whether EDC can

submit data (default is false)

false

1 0 0

Allow LSE to

submit data

Boolean whether LSE can

submit data (default is false)

false

1 0 0

Contact info 0..n 0..n

Interest Type Contact interest code Emergency 1 1

First Name First Name of contact John 1 1

Last Name Last name of contact Smith 1 1

Email Email of contact [email protected] 1 1

Phone Phone number of contact 910-328-1932 1 0

mailto:[email protected]



3.1.2 Location Diagram

3.1.3 Location XML Example

<Location>

<id>String</id>

<summaryInfo>

<name>String</name>

<CSP>

<name>String</name>

</CSP>

<EDC>

<name>String</name>

<accountNo>String</Account>

</EDC>

<zone>String</zone>

<status>String</status>

</summaryInfo>

<siteInfo>

<address>

<address1>String</address1>

<address2>String</address2>

<city>String</city>

<state>String</state>

<zipCode>String</zipCode>

</address>

<businessSegment>String</businessSegment>

<pNode>String</pNode>

</siteInfo>

<profileInfo>

<energyLossFactor>3.14159E0</energyLossFactor>

<capacityLossFactor>3.14159E0</capacityLossFactor>

<retailRate>3.14159E0</retailRate>

<loadReduction>3.14159E0</loadReduction>

<peakLoadContribution>3.14159E0</peakLoadContribution>

<loadMultiplier>0</loadMultiplier>

<generationFuelType>String</generationFuelType>

<meterQualificationDate>1967-08-13</meterQualificationDate>

<stateQualificationDate>1967-08-13</stateQualificationDate>

</profileInfor>

<reductionInfo>



<reductionType>HVAC</reductionType>

<reductionValue>3.14159E0</reductionValue>

</reductionInfo>

<meterInfo>

<meterOwner>EDC Meter</meterOwner>

<allowEDCtoSubmitData>false</allowEDCtoSubmitData>

<allowLSEtoSubmitData>false</allowLSEtoSubmitData>

</meterInfo>

<contactInfo>

<interestType>Flat Fixed</interestType>

<firstName>String</firstName>

<lastName>String</lastName>

<email>String</email>

<phone>String</phone>

</contactInfo>

</Location>

3.2 Registration

A Registration object is used to describe a collection of locations enrolled in a

specific DR program for a period of time.

3.2.1 Registration Fields

The following is a description of all the fields in a Registation object.


ID Registration object identifier 2637 1 1

Summary info 1 1 0

Reference Reference name of the

registration

R2637

1

Name Descriptive name of

registration or customer

Walmart

1 1 0

Type Type of registration Economic 1

Program Specific program name Economic

Energy 1 1

Start date Effective start date 10/24/2008 1 1

End date Termination date 10/24/2009 1 1

CSP Short name of the CSP PECO 1 1

EDC Short name of the EDC PGE 1 1

LSE Short name of the LSE ESI 1 1

Zone Short name of the zone PGE-WEST 1 1

Status Status of the location New 1

Location info 1..n 1..n 0..n

Location ID Unique location id 29281 1 1 1

EDCAccount EDC Account number 267827273 1

Energy Loss Factor Decimal loss factor 1.003 1 0

Capacity Loss

Factor

Decimal loss factor 1.003

1 0



Retail Rate Decimal retail rate (c/kwh) 20.5 0

Load Reduction Decimal value of location load

reduction (kw)

2000

1

Peak Load

Contribution


contibution (kw)

2000

1

Meter Qualification

Date

Date on which the meter was

qualified by PJM

12/1/2008

1

State Qualification

Expiry

Date on which state

qualification expires

1/1/2010

1

Energy info 0 0 0

Energy Type Energy Type Economic 1

Load Reduction Decimal value of aggregate

load reduction (kw)

2000

1

Energy Loss Factor Decimal loss factor (weighted

average of locations)

1.003

1

Strike Price Decimal of $/MW 150.25 1 0 0

Shutdown Costs Decimal of $ for shutdown 32000 1 0 0

Contract Type Contract type RT Index 1 1 0

Price Node Short name of the pricing (aka

aggregate) pnode

PGE-WEST

1 1 0

Retail Rate Decimal retail rate (c/kwh) 20.5 1 1 0

Rate Name Name describing the retail rate

of the site

E-1

1 0 0

Description Text description (or comment)

of the rate

‘Note: rate

changes on Apr

1 to 22.0

c/kwh’ 1 0 0

Emergency Emergency participation flag false 1

SelfSchedule Self-schedule participation flag true 1

DayAhead Day-ahead participation flag false 1

RealTime Real-time participation flag true 1

CBL Method CBL code Standard3 1 1

Weather Station Weather station code PHL 1

AS info 0

SynchReserve SR participation flag true 1

ScheduledReserve DASR participation flag false 1

Regulation Regulation participation flag false 1

BatchLoad Batch load flag false 1

Capacity info 0 0 0

Capacity Type Capacity type code DR 1

Lead Time Lead time (Long or Short) Long 1 1 0

Zone Area Zone area codes PGE-WEST 1 1 0



RPM Resource ID RPM bid award id (string) 3829282 1 1 0

Measurement

Method

Measurement type code FSL

1 1 0

Capacity Loss

Factor

Decimal loss factor (weighted

average of locations)

1.003

1

Peak Load

Contribution


contibution (kw)

300.5

1

ManagedLoad Decimal of FSL/GLD/DLC

amount

200.3

1 1 0

Multiplier Integer multiple number of

non-interval sites (default 1)

1

1 0 0

Nominal ICAP Decimal value of nominated

load

200.3

1

Other info 1 0 0

AllowEDCModify Allow EDC to modify flag false 1 0 0

AllowLSEModify Allow LSE to modify flag false 1 0 0

Hold Scheduling Hold scheduling flag false 1

Hold Settlements Hold settlements flag false 1

Comments Comments This is long

text 1 0 0

3.2.2 Registration Diagram

3.2.3 Registration XML Example

<Registration>

<id>String</id>

<summaryInfo>

<reference>String</reference>

<name>String</name>



<type>String</type>

<program>Economic-2008</program>

<startDate>1967-08-13</startDate>

<endDate>1967-08-13</endDate>

<CSP>

<name>String</name>

</CSP>

<EDC>

<name>String</name>

</EDC>

<LSE>

<name>String</name>

</LSE>

<zone>String</zone>


</summaryInfo>

<locationInfo>

<locationID>String</locationID>

<accountNo>String</accountNo>




<loadReduction>3.14159E0</loadReduction>


<siteMultiplier>1</siteMultiplier>

<generationFuelType>String</generationFuelType>

<meterQualificationDate>1967-08-13</meterQualificationDate>

<stateQualificationDate>1967-08-13</stateQualificationDate>

</locationInfo>

<energyInfo>

<energyType>String</energyType>

<loadReduction>String</loadReduction>


<strikePrice>3.14159E0</strikePrice>

<shutdownCosts>3.14159E0</shutdownCosts>

<contractType>String</contractType>

<priceNode>String</priceNode>


<rateName>String</rateName>

<rateDescription>String</rateDescription>

<emergency>true</emergency>

<selfSchedule>true</selfSchedule>

<dayAhead>true</dayAhead>

<realTime>true</realTime>

<CBLMethod>String</CBLMethod>

<weatherStation>String</weatherStation>

</energyInfo>

<ASInfo>

<synchronizedReserve>true</synchronizedReserve>

<scheduledReserve>true</scheduledReserve>

<regulation>true</regulation>

<batchLoad>true</batchLoad>

</ASInfo>

<capacityInfo>

<capacityType>String</capacityType>

<leadTime>true</leadTime>

<zoneArea>String</zoneArea>

<RPMResourceID>String</RPMResourceID>

<measurementMethod>String</measurementMethod>



<managedLoad>3.14159E0</managedLoad>

<multiplier>3.14159E0</multiplier>

<nominalICAP>3.14159E0</nominalICAP>

</capacityInfo>

<otherInfo>

<allowEDCtoModify>true</allowEDCtoModify>

<allowLSEtoModify>true</allowLSEtoModify>

<holdScheduling>false</holdScheduling>

<holdSettlements>false</holdSettlements>

<comment>String</comment>



</otherInfo>

</Registration>

3.3 Event

An Event object is used to describe a specific DR event – emergency, load

management, day-ahead, real-time, self-schedule, ancillary services, and outages.

3.3.1 Event Fields

The following is a description of all the fields in an Event object.

Field Description Example get

ID Event object identifier 2637 1

Summary info 1

Event Date Operating date of event start 1/24/2009 1

Event Type Type of event Emergency

Energy 1

Start time Operating start time of event 1/24/2009 1:20 1

End time Operating end time of event 1/25/2009 2:40 1

Description Description of event Line outage in

PECO 1

Short lead Short lead flag false 1

Long lead Long lead flag true 1

Status Status of the event Completed 1

Zone info 0..n

Zone Short name of all affected

zones

PGE-WEST

1

Registration info 0..n

Registration ID Unique registration id 2637 1


registration

R2637

1



Walmart

1

Type Type of registration Emergency 1

Program Specific program name DR Full 1

CSP Short name of the CSP PECO 1

EDC Short name of the EDC PGE 1

LSE Short name of the LSE ESI 1

Zone Short name of the zone PGE-WEST 1



3.3.2 Event Diagram

3.3.3 Event XML Example

<Event>

<id>String</id>

<summaryInfo>

<eventDate>1967-08-13</eventDate>

<eventType>String</eventType>

<startTime>2001-12-17T09:30:47.0Z</startTime>

<endTime>2001-12-17T09:30:47.0Z</endTime>

<description>String</description>

<shortLead>true</shortLead>

<longLead>true</longLead>


</summaryInfo>

<zoneInfo>

<zone>String</zone>

</zoneInfo>

<registrationInfo>

<registrationId>String</registrationId>


<name>String</name>

<type>String</type>

<program>String</program>

<CSP>

<name>String</name>

</CSP>

<EDC>

<name>String</name>

</EDC>

<LSE>

<name>String</name>

</LSE>

<zone>String</zone>

</registrationInfo>

</Event>

3.4 Settlement

A Settlement object is used to describe a DR event settlement or compliance

submission for a specific registration.



3.4.1 Settlement Fields

The following is a description of all the fields in a Settlement object.


ID Settlement object identifier 2637 1 1 1

Summary info 1

Event Date Operating date of event start 1/24/2009 1

Settlement Type Type of settlement Economic

Energy 1

Compliance Only Compliance only flag false 1

Start time Operating start time of event 1/24/2009 1:20 1

End time Operating end time of event 1/25/2009 2:40 1

CBLMethod CBL Code Standard3 1

Valid As Of Date Date the cbl calculation was

last run

2009-04-28

1

Validation Message Message from the last run Baseline and

reduction

calculated

successfully 1

Validation Status Status of last CBL run Success 1

Bill Date Bill cycle date 2/1/2009 1

Adjustment Adjustment flag false 1 1

Status Status of the settlement Pending 1

Registration info 1

Registration ID Unique registration id 2637 1


registration

R2637

1



Walmart

1

Type Type of registration Emergency 1

Program Specific program name DR Full 1

CSP Short name of the CSP PECO 1

EDC Short name of the EDC PGE 1

LSE Short name of the LSE ESI 1

Zone Short name of the zone PGE-WEST 1

Settlement info 1..n 1..n 1..n

Event Hour Hour ending 15 1 1 1

GMT Hour GMT Hour beginning 1/24/2009

14:00 1

Reduction Hour Flag indicating whether to

settle

true

1 0 0

Market Type Market type indicator RT 1

Baseline Decimal baseline value (kw) 340.2 1



Load Decimal load value (kw) 220.2 1

Reduction Decimal reduction value (kw) 120.2 1

Rate Decimal retail rate (c/kw) 20.2 1 0 0

Loss Factor Decimal loss factor 1.003 1 0 0

Scheduled Decimal scheduled value (kw) 220.2 1

Dispatched Decimal dispatched value (kw) 120.2 1

DA Price Decimal DA LMP $/kwh 87.23 1

RT Price Decimal RT LMP $/kwh 87.23 1

Totals info 0

Total Reduction Decimal total load reduction 2400.2 1

AverageRate Decimal average retail rate 20.4 1

AverageLoss Decimal average loss factor 1.002 1

Other info 1 0

AllowEDCModify Allow EDC to modify flag false 1 0

AllowLSEModify Allow LSE to modify flag false 1 0

Comments Comments long text 1 0

3.4.2 Settlement Diagram

3.4.3 Settlement XML Example

<Settlement>

<id>String</id>

<summaryInfo>

<eventDate>1967-08-13</eventDate>

<settlementType>Economic Energy</settlementType>

<complianceOnly>true</complianceOnly>

<startTime>2001-12-17T09:30:47.0Z</startTime>

<endTime>2001-12-17T09:30:47.0Z</endTime>

<CBLMethod>String</CBLMethod>

<billDate>1967-08-13</billDate>

<adjustment>true</adjustment>




</summaryInfo>

<registrationInfo>



<name>String</name>

<type>String</type>

<program>String</program>

<CSP>

<name>String</name>

</CSP>

<EDC>

<name>String</name>

</EDC>

<LSE>

<name>String</name>

</LSE>

<zone>String</zone>

</registrationInfo>

<settlementInfo>

<eventHour>0</eventHour>

<GMTHour>2001-12-17T09:30:47.0Z</GMTHour>

<reductionHour>true</reductionHour>

<marketType>String</marketType>

<baseline>3.14159E0</baseline>

<load>3.14159E0</load>

<reduction>3.14159E0</reduction>

<rate>3.14159E0</rate>

<lossFactor>3.14159E0</lossFactor>

<scheduled>3.14159E0</scheduled>

<dispatched>3.14159E0</dispatched>

<DAPrice>3.14159E0</DAPrice>

<RTPrice>3.14159E0</RTPrice>

</settlementInfo>

<totalInfo>

<totalReduction>3.14159E0</totalReduction>

<averageRate>3.14159E0</averageRate>

<avergeLoss>3.14159E0</avergeLoss>

</totalInfo>

<otherInfo>

<allowEDCtoModify>true</allowEDCtoModify>

<allowLSEtoModify>true</allowLSEtoModify>

<comment>String</comment>

</otherInfo>

</Settlement>

3.5 Process

A Process object is used to describe a task, set of tasks, and task completions related

to work-flow processes within the system.

3.5.1 Process Fields

The following is a description of all the fields in a Process object.

Field Description Example get change

ID Process identifier 2637 1 1

Summary info 1

Process name Type of process Approve

Registration 1 1

Process owner Organization who initiated the

process

AEP

1



Start Date Date process began 1/21/2009 1

End Date Date process ended (if ended) 1/22/2009 1

Status Status of process Denied 1

Object id Id of related object 18278 1 1

Object type Object type (Registration,

Settlement)

Registration

1 1

Task info 1..n 1

Task name Name of task EDC Review 1 1

Task org Organization the task is

assigned

PECO

1

Task user User the task is assigned rmick 1

Task priority Priority of task 2 1

Task started Date/time task was created 11/6/2008 1

Task due Date/time task is due 11/8/2008 1

Task completed Date/time task was completed

(null if open)

11/10/2008

1

Task status Status of task Denied 1

Reasons Comma separated list of

reasons

Invalid meter

0

Comments Comment from task user Wrong number 0

Decision 0..n 1

Decision name Name of Decision Deny 1 1

Decision \ Reasons 0..n 0..n

Reason name Name of reason Invalid meter 1 1

Attributes 0..n

Attribute Name of attribute NewEndDate 1

Attribute Type Data type of attribute DATETIME 1

Initial Value String value representing the

attribute

‘12/31/2009’

1

Value String value representing the

attribute

‘12/31/2009’

1

Readonly Flag indicating read-only true 1



3.5.2 Process Diagram

3.5.3 Process XML Example

<Process>

<id>String</id>

<summaryInfo>

<processName>String</processName>

<processOwner>String</processOwner>

<startDate>1967-08-13</startDate>

<endDate>1967-08-13</endDate>


<objectID>String</objectID>

<objectType>String</objectType>

</summaryInfo>

<taskInfo>

<taskName>String</taskName>

<taskOrg>String</taskOrg>

<taskUser>String</taskUser>

<taskPriority>0</taskPriority>

<taskStarted>1967-08-13</taskStarted>

<taskDue>1967-08-13</taskDue>

<taskCompleted>1967-08-13</taskCompleted>

<taskStatus>String</taskStatus>

<reasons>String</reasons>

<comments>String</comments>

</taskInfo>

<decisionInfo>

<decisionName>String</decisionName>

<decisionReasons>

<reasonName>String</reasonName>

</decisionReasons>

</decisionInfo>

<attributeInfo>

<attribute>String</attribute>

<attributeType>String</attributeType>

<initialValue>String</initialValue>

<value>String</value>

<readOnly>true</readOnly>

</attributeInfo>

</Process>



3.6 Daily Data

A Daily Data object is used to describe an entire operating day of measurement data

for a given location of a specific measurement type. Currently this is used for 24 (or

23 or 25) intervals of measurement data, typically as part of settlements.

3.6.1 Daily Data Fields

The following is a description of all the fields in a Daily Data object.

Field Description Example get create

Summary info 1 1

Location id Unique id of location 12837 1 1

Registration id Unique id of registration 3526 0

EDC EDC short name PECO 1

EDC Account EDC account # PEC28329 1

Measurements 1 1

Datestamp Operating Date 10/7/2008 1 1

Type Enumerated type of submission DailyLoad 1 1

UOM Enumerated type of data KW 1 1

Intervals Number of intervals provided

(typically 24 – 23 or 25 also

allowed)

24

1 1

Values Comma separated string of

#interval values

273.2,284.5,,,

1 1

Latest Latest submission flag true 1

Submitted by User name of submitter mday 1

Submitted date Date-time of submission 10/8/2008 5:30 1

3.6.2 Daily Data Diagram

3.6.3 Daily Data XML Example

<DailyData>

<summaryInfo>

<locationId>String</locationId>


<EDC>



<name>String</name>

<accountNo>String</account>

</EDC>

</summaryInfo>

<measurementInfo>

<dateStamp>1967-08-13</dateStamp>

<type>String</type>

<UOM>String</UOM>

<intervals>0</intervals>

<values>3.14159E0</values>

<latest>true</latest>

<submittedBy>String</submittedBy>

<submittedate>2001-12-17T09:30:47.0Z</submittedate>

</measurementInfo>

</DailyData>

3.7 Interval Data

An Interval Data object is used to describe a random interval of measurement data for

a given location of a specific measurement type. Currently this is used for event

compliance submissions.

3.7.1 Interval Data Fields

The following is a description of all the fields in a Interval Data object.

Field Description Example get create

Summary info 1 1

Location id Unique id of location 12837 1 1

Registration id Unique id of registration 3526 0

EDC EDC short name PECO 1

EDC Account EDC account # PEC28329 1

Measurements 1..n 1..n

Timestamp Operating time 10/7/08 5:23 1 1

Type Enumerated type of submission MinuteLoad 1 1

UOM Enumerated type of data KW 1 1

Value Value for interval 273.4 1 1

Latest Latest submission flag (1=

latest, otherwise 0)

true

1

Submitted by User name of submitter mday 1

Submitted date Date-time of submission 10/8/2008 5:30 1

3.7.2 Interval Data Diagram



3.7.3 Interval Data XML Example

<IntervalData>

<summaryInfo>

<locationId>String</locationId>


<EDC>

<name>String</name>

<accountNo>String</acountNo>

</EDC>

</summaryInfo>

<measurementInfo>

<timestamp>2001-12-17T09:30:47.0Z</timestamp>

<type>String</type>

<UOM>String</UOM>

<value>3.14159E0</value>

<latest>true</latest>

<submittedBy>String</submittedBy>

<submittedDate>2001-12-17T09:30:47.0Z</submittedDate>

</measurementInfo>

</IntervalData>

3.8 Alert Data

3.8.1 Alert Data Fields

The following is a description of all the fields in an Alert Data object.

Field Description Example get

Subject Subject line of Alert 1

Message Message body of the alert 1

Object Type The object type the alert applies

to (Registration. Settlement,

Event)

Registration

1

Object Id The ID of the object the

message pertains to

200

1

Expiration Date The expiration date of the alert 10/7/08 5:23 1

Urgent Flag indicating if the message

is urgent

False

1



3.8.2 Alert Data Diagram

3.8.3 Interval Data XML Example

<Alert>

<subject>subject</subject>

<message>message</message>

<objectType>objectType</objectType>

<objectId>0</objectId>

<expirationDate>2001-01-01</expirationDate>

<urgent>true</urgent>

</Alert>



4 Load Response Information The purpose of the LRInformation Service is to support interfaces required for

retrieving Load Response (LR) related information. These are read-only interfaces, as

opposed to transactional interfaces.

Note: The interfaces described in this section are subject to change based upon

final DRBizNet design.

4.1 Interfaces Provided

Specific interfaces using specific combinations of verbs and nouns (i.e. payload

types) are defined to permit a DR participant to programmatically access DR

information. The verb to be used for requests would in all cases be ‘get’. The noun

would identify the type of information being requested. Each request could use a

message ‘Request’ package to specify one or more parameters that would qualify the

request.

The processing sequence is shown in the following sequence diagram.

LRS Users Web

Services ClientBigIP Proxy LRS Application

1: Request (get)

5: Authorize

6: Reply

7: Response (reply, noun, payload)

4: Invoke LRS API

3: Authentication

Integration

Tibco Layer

2:: Request (get)


HTTPS

PJM LRS SYSTEM

HTTP

HTTPS

HTTP

CSP/EDC/LSE WS Client PJM DMZ

Figure 7 - LR Information Request Sequence Diagram



4.2 Interfaces Required

The messages for LR information requests would use the following message fields:

Message Element Value

Header/Verb Get

Header/Noun Name of payload type

Header/Source DR participant ID

Header/UserID Optional: ID of user

Request/? Optional: Other request parameters may be specified as needed

Payload Message payload data with type defined by Noun

The corresponding response messages would use the following message fields:


Header/Verb Reply

Header/Noun Defined payload type name

Header/Source PJM

Reply/ReplyCode Reply code, success=OK, error=ERROR or FATAL

Reply/Error May be any number of error messages

Payload Defined payload type

In the cases of payloads that would otherwise exceed 1 megabyte, the payloads would

be zipped, base64 encoded and stored within the ‘Payload/Compressed’ tag.



4.3 Message Specifications

LRS Information Payload definitions are dataset specific and are described in this section.

4.3.1 Location

Location related information use cases include -

Description Verb Noun Input Output

Get location get location Request/ID=

location id

Payload=location

object

Search locations

by name or edc

account number

get location Request/Match=

string

Payload=set of

location objects

The Get Location interface provides the means for a DR participant to obtain

Location Information. The following parameters are specified in the RequestMessage:


Header/Verb get

Header/Noun location

Header/Source LR participant ID


Request/ID Optional: Location ID of interest

Request/Match Optional: Location partial name or EDC Account number



Header/Verb reply


Header/Source PJM

Reply/ReplyCode Reply code, success=ok, error=fatal or



warning

Reply/Error Error message, if error encountered

Payload Location(s)

4.3.2 Registration

Registration related information use cases include -


Get registration get registration Request/ID=

registration id

Payload=

registration object

Search

registrations

active within a

date range

get registration Request/StartTime=

search start date

Request/EndTime=

search end date

Payload= set of

registration objects

The Get Registration interface provides the means for a DR participant to obtain

Registration Information. The following parameters are specified in the

RequestMessage:


Header/Verb get

Header/Noun registration



Request/ID Optional: Registration ID of interest

Request/StartTime Optional: Start Time of interest

Request/EndTime Optional: End Time of interest



Header/Verb reply




Header/Source PJM

Reply/ReplyCode Reply code, success=ok, error=fatal or warning


Payload Registration(s)

4.3.3 Event

Event related information use cases include -


Get event get event Request/ID=

event id

Payload=

event object

Search events

within a date

range

get event Request/StartTime =

search start date

Request/EndTime=

search end date

Payload= set of

event objects

The Get Event interface provides the means for a DR participant to obtain Event

Information. The following parameters are specified in the RequestMessage:


Header/Verb get

Header/Noun event



Request/ID Optional: Event ID of interest

Request/StartTime Optional: Start Time of interest

Request/EndTime Optional: End Time of interest





Header/Verb reply

Header/Noun event

Header/Source PJM



Payload Event(s)

4.3.4 Alert

Alert related information use cases include -


Get alert get alert Request/StartTime =

search start date

Request/EndTime=

search end date

Payload=

alert object(s)

The Get Alert interface provides the means for a DR participant to obtain Alert

Information. The following parameters are specified in the RequestMessage:


Header/Verb get

Header/Noun alert



Request/ID n/a

Request/StartTime Required: Start Time of issued date

Request/EndTime Required: End Time of issued date





Header/Verb reply

Header/Noun alert

Header/Source PJM



Payload Event(s)

4.3.5 Settlement

Settlement related information use cases include -


Get settlement get settlement Request/ID=

settlement id

Payload=

settlement object

Search

settlements within

a date range

get settlement Request/StartTime=

search start date

Requent/EndTime=

search end date

Payload= set of

settlement objects

The Get Settlement interface provides the means for a DR participant to obtain

Settlement Information. The following parameters are specified in the

RequestMessage:


Header/Verb get

Header/Noun settlement



Request/ID Optional Settlement ID of Interest

Request/StartTime Optional: Start date of event

Request/EndTime Optional: End date of event





Header/Verb reply


Header/Source PJM



Payload Settlement(s)

4.3.1 Process

Process related information use cases include -


Search pending

processes

assigned to

organization

get process Payload= set of

process objects

Get process status

and history

get process Request/ID=

process id

Payload=

process object

Search pending

processes started

by organization

get process Request/

Organization =

short name of

organization

Payload= set of

process objects

The Get Process interface provides the means for a DR participant to obtain detailed

Process information. The following parameters are specified in the RequestMessage:


Header/Verb get

Header/Noun process





Request/ID Optional: Process ID of Interest

Request/Organization Optional: Organization of interest (must match participant ID)



Header/Verb reply

Header/Noun process

Header/Source PJM



Payload Process(s)

4.3.2 Measurement Data

Measurement Data related information use cases include -


Gets submitted

daily data for a

location and date

range

get dailydata Request/ID=

location id

Request/StartTime=

start date

Request/EndTime=

end date

Payload= set of

daily data

objects

Gets submitted

daily data for a

registration and

date range

get dailydata Request/AlternateID=

registration id

Request/StartTime=

starttime

Request/EndTime=

endtime

Payload= set of

daily data

objects

Gets submitted

interval data for

a location and

date range

get intervaldata Request/ID=

location id

Request/StartTime=

start date

Request/EndTime=

end date

Payload= set of

interval data

objects



Gets submitted

interval data for

a registration

and date range

get intervaldata Request/AlternateID=

registration id

Request/StartTime=

starttime

Request/EndTime=

endtime

Payload= set of

interval data

objects

4.3.2.1 ‘get’ dailydata or intervaldata

The following parameters are specified in the RequestMessage:


Header/Verb get

Header/Noun dailydata or intervaldata



Request/ID Optional: Location id

Request/Alternate ID Optional: Registration id

Request/Start time Start date-time of reads

Request/End time End date-time of reads



Header/Verb reply

Header/Noun dailydata or intervaldata

Header/Source PJM



Payload DailyData(s) or IntervalData(s)



The payload objects will contain all available fields, with the exception that the

Registration Id will only be populated if it was part of the search criteria.



5 Load Response Transactions

The purpose of the Load Response Transactions (LRTransaction) Service is to support

interfaces required for LR Transactions. This section describes the use of web services by

PJM Customers that involve the creation, submission, change, and cancellation of

Registrations, Location, Settlement, etc.

Note: The interfaces described in this section are subject to change based upon

final DRBizNet design.

5.1 Interfaces Provided

Specific interfaces using specific combinations of verbs and nouns (i.e. payload

types) are defined to permit a PJM LR participant to programmatically interact with

LR Transactions.

The verb to be used for requests would be one of {create, change, action, cancel}.

The noun would identify the type of transaction being requested. Each request could

use a message ‘Request’ package to specify one or more parameters that would

qualify the request.

The processing sequence is shown in the following sequence diagram.



LRS Users Web

Services ClientBigIP Proxy LRS Application

1: Request (create, change, cancel)

5: Authorize

6: Reply


4: Invoke LRS API

3: Authentication

Integration

Tibco Layer

2:: Request (create, change, cancel)


HTTPS

PJM LRS SYSTEM

HTTP

HTTPS

HTTP

CSP/EDC/LSE WS Client PJM DMZ

Figure 8 - LR Transaction Request Sequence Diagram

5.2 Interfaces Required

The messages for LR information requests would use the following message fields for

creation or update (change) of a record:


Header/Verb create/change


Header/Source Org short name


Request/? Optional: Other request parameters may be specified as needed

Payload Message payload data with type defined by Noun



The corresponding response messages for create or update would use the following

message fields:


Header/Verb reply


Header/Source PJM


Reply/Error May be any number of error message if the ReplyCode is ERROR

Reply/Timestamp The time the submission was received by PJM

Reply/ID Process id (if PENDING)

Payload Message payload data with type defined by Noun.

In the cases of payloads that would otherwise exceed 1 megabyte, the payloads would

be zipped, base64 encoded and stored within the ‘Payload/Compressed’ tag.

The messages for LR information requests would use the following message fields for

cancellation (delete) of a record:


Header/Verb cancel




Request/ID Required: ID of the record to be deleted

The corresponding response messages for cancel would use the following message

fields:




Header/Verb reply


Header/Source PJM


Reply/Error May be any number of error message if the ReplyCode is ERROR


Reply/Timestamp The time the submission was received by PJM

5.3 Message Specifications

LRS Transaction verb, noun and payload definitions are dataset specific and are described in

this section.

5.3.1 Location

Location related transactional use cases include –


Create a new

location

create location Request/Option=

new

Payload=location

object

Reply/ID=

process id

Payload=location

object

Update a

location

change location Request/Option=

detail

Payload=

location object

Reply/ID=

process id

5.3.1.1 ‘create’ Location

The ‘create’ Location interface provides the means for a DR participant to create a

Location. The following parameters are specified in the RequestMessage:


Header/Verb create






Request/Option {new, [future]}

Payload Location



Header/Verb reply


Header/Source PJM




Payload Location

5.3.1.2 ‘change’ Location

The ‘change’ Location interface provides the means for a DR participant to change a

Location. The following parameters are specified in the RequestMessage:


Header/Verb change




Request/Option {detail, [future]}

Payload Location





Header/Verb reply


Header/Source PJM




5.3.2 Registration

Registration related transactional use cases include –


Create a new

registration

create registration Request/Option=

new

Payload=

registration object

Reply/ID=

process id

Payload= registration

object

Create a new

registration

and submit

for approval

create registration Request/Option=

submit

Payload=

registration object

Reply/ID=

process id

Payload= registration

object

Update

registration

details

change registration Request/Option=

detail

Payload=

registration object

Reply/ID=

process id

Submit a

registration

for approval

action registration Request/Option=

submit

Request/ID=

registration id

Reply/ID=

process id

Withdraw a

pending

registration

action registration Request/Option=

withdraw

Request/ID=

registration id

Reply/ID=

process id



5.3.2.1 ‘create’ Registration

The ‘create’ Registration interface provides the means for a LR participant to create

Registration Information. The following parameters are specified in the

RequestMessage:


Header/Verb create




Request/Option {new, submit, [future]}

Payload Registration



Header/Verb reply


Header/Source PJM



Reply/id Process ID (if PENDING)


5.3.2.2 ‘change’ Registration

The ‘change’ Registration interface provides the means for a LR participant to change

their Registration Information. The following parameters are specified in the

RequestMessage:


Header/Verb change






Request/Option {details, [future]}




Header/Verb reply


Header/Source PJM



Reply/ID Process ID (if PENDING)

5.3.2.3 ‘action’ Registration

The ‘action’ Registration interface provides the means for a LR participant to initiate

an action on a Registration. The following parameters are specified in the

RequestMessage:


Header/Verb action




Request/Option {submit, withdraw,[ future]}

Request/ID Registration ID





Header/Verb reply


Header/Source PJM




5.3.3 Event

There is no create/change Event interface at this time. (Self-scheduled events will be

done outside LRS).

5.3.4 Settlement

Settlement related transactional use cases include –


Update the

settlement

change settlement Payload=

settlement object

Reply/ID=

process id

Validate a

settlement

action settlement Request/Option=

validate

Request/ID=

settlement id

Withdraw a

settlement

action settlement Request/Option=

withdraw

Request/ID=

settlement id

Reply/ID=

process id

Create a

settlement

adjustment

create settlement Request/Option=

adjustment

Payload=

settlement object

Reply/ID=

Payload=settlement

object



5.3.4.1 ‘change’ Settlement

The change Settlement interface provides the means for a LR participant to change

their Settlement Information. The following parameters are specified in the

RequestMessage:


Header/Verb change




Request/Option {detail, [future]}

Payload Settlement



Header/Verb reply


Header/Source PJM




5.3.4.2 ‘action’ Settlement

The action Settlement interface provides the means for a LR participant to initiate an

action on a Settlement. The following parameters are specified in the

RequestMessage:


Header/Verb action






Request/Option {submit, withdraw, validate, [future]}



Header/Verb reply


Header/Source PJM




5.3.4.3 ‘create’ Settlement

The create Settlement interface provides the means for a LR participant to create an

adjustment on an existing closed Settlement. The following parameters are specified

in the RequestMessage:


Header/Verb create




Request/Option {adjustment, [future]

Payload Settlement





Header/Verb reply


Header/Source PJM




5.3.5 Process

Process related transactional use cases include –


Complete an

assigned

process task

(approve, deny,

etc)

change process Request/Option=

completetask

Payload= process

object

Reply/ID=

process id

5.3.5.1 ‘change’ Process

The change Process interface provides the means for a LR participant to update a

Process state, typically to complete an assigned task. The following parameters are

specified in the RequestMessage:


Header/Verb change

Header/Noun process



Request/Option {completetask, [future]}

Payload Process





Header/Verb reply

Header/Noun process

Header/Source PJM



Reply/ID Process ID

5.3.6 Measurement Data

Measurement Data related transactional use cases include –


Upload daily

measurement data

create dailydata Payload=Daily

data

Reply/ID=

process id

Upload interval

measurement data

create intervaldata Payload=Interval

data

Reply/ID=

process id

5.3.6.1 ‘create’ Daily Data

The create DailyData interface provides the means for a DR participant to upload

(i.e., ‘submit’) DailyData Information, typically for settlement. The following

parameters are specified in the RequestMessage:


Header/Verb create

Header/Noun dailydata



Payload DailyData





Header/Verb reply

Header/Noun dailydata

Header/Source PJM




5.3.6.2 ‘create’ Interval Data

The create IntervalData interface provides the means for a DR participant to create

(i.e., ‘submit’) IntervalData Information, typically for compliance. The following

parameters are specified in the RequestMessage:


Header/Verb change

Header/Noun intervaldata



Payload IntervalData



Header/Verb reply

Header/Noun intervaldata

Header/Source PJM




Appendix A: WSDL for DR Requests This WSDL uses a set of operations for servicing all DR requests, related to information requests and alert acknowledgements.

<?xml version="1.0" encoding="UTF-8"?>



<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://www.uisol.com/wsdl/2009/LRSConcrete"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:ns="http://www.uisol.com/schema/drbiznet/2009/message" name="Untitled"

targetNamespace="http://www.uisol.com/wsdl/2009/LRSConcrete">

<wsdl:types>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.uisol.com/schema/drbiznet/2009/message"

elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:include schemaLocation="Message.xsd"/>

</xs:schema>

</wsdl:types>

<wsdl:message name="AlertRequest">

<wsdl:part name="Message" element="ns:AlertRequest"/>

</wsdl:message>

<wsdl:message name="InformationRequest">

<wsdl:part name="Message" element="ns:InformationRequest"/>

</wsdl:message>

<wsdl:message name="TransactionRequest">

<wsdl:part name="Message" element="ns:TransactionRequest"/>

</wsdl:message>

<wsdl:message name="ResponseMessage">

<wsdl:part name="Message" element="ns:ResponseMessage"/>

</wsdl:message>

<wsdl:message name="FaultMessage">

<wsdl:part name="part1" element="ns:FaultMessage"/>

</wsdl:message>

<wsdl:portType name="Operations">

<wsdl:operation name="LRSTransactions">

<wsdl:input message="tns:TransactionRequest"/>

<wsdl:output message="tns:ResponseMessage"/>



<wsdl:fault name="fault1" message="tns:FaultMessage"/>

</wsdl:operation>

<wsdl:operation name="Alerts">

<wsdl:input message="tns:AlertRequest"/>



</wsdl:operation>

<wsdl:operation name="LRSInformation">

<wsdl:input message="tns:InformationRequest"/>



</wsdl:operation>

</wsdl:portType>

<wsdl:binding name="HTTPEndPointBinding" type="tns:Operations">

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

<wsdl:operation name="LRSTransactions">

<soap:operation soapAction="/BusinessService/DRBizNetEWSService.serviceagent/HTTPEndPoint/LRSTransactions"

style="document"/>

<wsdl:input>

<soap:body parts="Message" use="literal"/>

</wsdl:input>

<wsdl:output>


</wsdl:output>

<wsdl:fault name="fault1">

<soap:fault name="fault1" use="literal"/>

</wsdl:fault>

</wsdl:operation>

<wsdl:operation name="Alerts">

<soap:operation soapAction="/BusinessService/DRBizNetEWSService.serviceagent/OperationsEndpoint1/Alerts" style="document"/>

<wsdl:input>


</wsdl:input>

<wsdl:output>


</wsdl:output>





</wsdl:fault>

</wsdl:operation>

<wsdl:operation name="LRSInformation">

<soap:operation soapAction="/BusinessService/DRBizNetEWSService.serviceagent/HTTPEndPoint/LRSInformation"

style="document"/>

<wsdl:input>


</wsdl:input>

<wsdl:output>


</wsdl:output>



</wsdl:fault>

</wsdl:operation>

</wsdl:binding>

<wsdl:service name="DRBizNetEWSService">

<wsdl:port name="HTTPEndPoint" binding="tns:HTTPEndPointBinding">

<soap:address location="http://UISOL-1:9696/BusinessService/DRBizNetEWSService.serviceagent/HTTPEndPoint"/>

</wsdl:port>

</wsdl:service>

</wsdl:definitions>



Appendix B: XML Schemas The following XML schema is used to define Message structures for request and response messages for the WSDL defined in

Appendix B. These are provided here for reference purposes, but versions should be downloaded from the PJM web site for

development use.

message.xsd


<xsd:schema xmlns="http://www.uisol.com/schema/drbiznet/2009/message" xmlns:xsd="http://www.w3.org/2001/XMLSchema"

targetNamespace="http://www.uisol.com/schema/drbiznet/2009/message" elementFormDefault="qualified" attributeFormDefault="unqualified"

version="0.0.1">

<xsd:complexType name="RequestType">

<xsd:sequence>

<xsd:element name="Date" type="xsd:dateTime" minOccurs="0"/>

<xsd:element name="StartTime" type="xsd:dateTime" minOccurs="0"/>

<xsd:element name="EndTime" type="xsd:dateTime" minOccurs="0"/>

<xsd:element name="Zone" type="xsd:string" minOccurs="0"/>

<xsd:element name="Option" type="xsd:string" minOccurs="0"/>

<xsd:element name="Match" type="xsd:string" minOccurs="0"/>

<xsd:element name="Organization" type="xsd:string" minOccurs="0"/>

<xsd:element name="ID" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element name="AlternateID" type="xsd:string" minOccurs="0"/>

<xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="ReplyType">

<xsd:sequence>

<xsd:element name="ReplyCode" type="xsd:string"/>

<xsd:element name="Error" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element name="Timestamp" type="xsd:dateTime" minOccurs="0"/>

<xsd:element name="ID" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>


</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="PayloadType">



<xsd:sequence>

<xsd:choice>

<xsd:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element name="Document" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element name="Compressed" type="xsd:string" minOccurs="0"/>

</xsd:choice>

<xsd:element name="format" type="xsd:string" minOccurs="0"/>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="HeaderType">

<xsd:sequence>

<xsd:element name="Verb" default="get">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="cancel"/>

<xsd:enumeration value="canceled"/>

<xsd:enumeration value="change"/>

<xsd:enumeration value="changed"/>

<xsd:enumeration value="create"/>

<xsd:enumeration value="created"/>

<xsd:enumeration value="close"/>

<xsd:enumeration value="closed"/>

<xsd:enumeration value="delete"/>

<xsd:enumeration value="deleted"/>

<xsd:enumeration value="get"/>

<xsd:enumeration value="reply"/>

<xsd:enumeration value="submit"/>

<xsd:enumeration value="action"/>

<xsd:enumeration value="update"/>

<xsd:enumeration value="updated"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="Noun" type="xsd:string"/>

<xsd:element name="Revision" type="xsd:string" default="001"/>

<xsd:element name="Source" type="xsd:string"/>

<xsd:element name="UserID" type="xsd:string" minOccurs="0"/>



<xsd:element name="MessageID" type="xsd:string" minOccurs="0"/>

<xsd:element name="Comment" type="xsd:string" minOccurs="0"/>


</xsd:sequence>

</xsd:complexType>

<xsd:element name="Message">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Header" type="HeaderType"/>

<xsd:choice>

<xsd:element name="Request" type="RequestType" minOccurs="0"/>

<xsd:element name="Reply" type="ReplyType" minOccurs="0"/>

</xsd:choice>

<xsd:element name="Payload" type="PayloadType" minOccurs="0"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:complexType name="RequestMessageType">

<xsd:sequence>


<xsd:element name="Request" type="RequestType" minOccurs="0"/>


</xsd:sequence>

</xsd:complexType>

<xsd:element name="InformationRequest" type="RequestMessageType"/>

<xsd:element name="TransactionRequest" type="RequestMessageType"/>

<xsd:element name="AlertRequest" type="RequestMessageType"/>

<xsd:element name="ResponseMessage">

<xsd:complexType>

<xsd:sequence>




</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="FaultMessage">

<xsd:complexType>

<xsd:sequence>


</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

LRSLocation.xsd




<xs:schema xmlns="http://www.pjm.com/schema/drbiznet/2009/model" xmlns:xs="http://www.w3.org/2001/XMLSchema"

targetNamespace="http://www.pjm.com/schema/drbiznet/2009/model" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:include schemaLocation="LRSCommonTypes.xsd"/>

<xs:element name="Locations">

<xs:complexType>

<xs:sequence>

<xs:element ref="Location" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:complexType name="locationSummaryInfoType">

<xs:sequence>

<xs:element name="name" type="xs:string" minOccurs="0"/>

<xs:element name="CSP" type="organization" minOccurs="0"/>

<xs:element name="EDC" type="organization" minOccurs="0"/>

<xs:element name="zone" type="xs:string" minOccurs="0"/>

<xs:element name="status" type="xs:string" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="locationSiteInfoType">

<xs:sequence>



<xs:element name="address" type="address" minOccurs="0"/>

<xs:element name="businessSegment" type="xs:string" minOccurs="0"/>

<xs:element name="pNode" type="xs:string" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="locationProfileInfoType">

<xs:sequence>

<xs:element name="energyLossFactor" type="xs:double" minOccurs="0"/>

<xs:element name="capacityLossFactor" type="xs:double" minOccurs="0"/>

<xs:element name="retailRate" type="xs:double" minOccurs="0"/>

<xs:element name="loadReduction" type="xs:double" minOccurs="0"/>

<xs:element name="peakLoadContribution" type="xs:double" minOccurs="0"/>

<xs:element name="loadMultiplier" type="xs:double" minOccurs="0"/>

<xs:element name="generationFuelType" type="xs:string" minOccurs="0"/>

<xs:element name="meterQualificationDate" type="xs:date" minOccurs="0"/>

<xs:element name="stateQualificationDate" type="xs:date" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="locationReductionInfoType">

<xs:sequence>

<xs:element name="reductionType" type="xs:string" minOccurs="0"/>

<xs:element name="reductionValue" type="xs:double" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="locationMeterInfoType">

<xs:sequence>

<xs:element name="meterOwner" type="xs:string" minOccurs="0"/>

<xs:element name="allowEDCtoSubmitData" type="xs:boolean" minOccurs="0"/>

<xs:element name="allowLSEtoSubmitData" type="xs:boolean" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:element name="Location">

<xs:annotation>

<xs:documentation>LRS Location Object</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>



<xs:element name="id" type="objectId" minOccurs="0"/>

<xs:element name="summaryInfo" type="locationSummaryInfoType" minOccurs="0"/>

<xs:element name="siteInfo" type="locationSiteInfoType" minOccurs="0"/>

<xs:element name="profileInfo" type="locationProfileInfoType" minOccurs="0"/>

<xs:element name="reductionInfo" type="locationReductionInfoType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="meterInfo" type="locationMeterInfoType" minOccurs="0"/>

<xs:element name="contactInfo" type="contact" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

LRSRegistration.xsd <?xml version="1.0" encoding="UTF-8"?>





<xs:element name="Registrations">

<xs:complexType>

<xs:sequence>

<xs:element ref="Registration" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:complexType name="registrationSummaryType">

<xs:sequence>

<xs:element name="reference" type="xs:string" minOccurs="0"/>


<xs:element name="type" type="xs:string" minOccurs="0"/>

<xs:element name="program" type="xs:string" minOccurs="0"/>

<xs:element name="startDate" type="xs:date" minOccurs="0"/>

<xs:element name="endDate" type="xs:date" minOccurs="0"/>



<xs:element name="LSE" type="organization" minOccurs="0"/>





</xs:sequence>

</xs:complexType>

<xs:complexType name="registrationLocationType">

<xs:sequence>

<xs:element name="locationID" type="objectId" minOccurs="0"/>

<xs:element name="accountNo" type="xs:string" minOccurs="0"/>




<xs:element name="loadReduction" type="xs:double" minOccurs="0"/>


<xs:element name="siteMultiplier" type="xs:double" default="1" minOccurs="0"/>

<xs:element name="generationFuelType" type="xs:string" minOccurs="0"/>

<xs:element name="meterQualificationDate" type="xs:date" minOccurs="0"/>

<xs:element name="stateQualificationDate" type="xs:date" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="registrationEnergyType">

<xs:sequence>

<xs:element name="energyType" type="xs:string" minOccurs="0"/>

<xs:element name="loadReduction" type="xs:string" minOccurs="0"/>


<xs:element name="strikePrice" type="xs:double" minOccurs="0"/>

<xs:element name="shutdownCosts" type="xs:double" minOccurs="0"/>

<xs:element name="contractType" type="xs:string" minOccurs="0"/>

<xs:element name="priceNode" type="xs:string" minOccurs="0"/>


<xs:element name="rateName" type="xs:string" minOccurs="0"/>

<xs:element name="rateDescription" type="xs:string" minOccurs="0"/>

<xs:element name="emergency" type="xs:boolean" minOccurs="0"/>

<xs:element name="selfSchedule" type="xs:boolean" minOccurs="0"/>

<xs:element name="dayAhead" type="xs:boolean" minOccurs="0"/>

<xs:element name="realTime" type="xs:boolean" minOccurs="0"/>

<xs:element name="CBLMethod" type="xs:string" minOccurs="0"/>

<xs:element name="weatherStation" type="xs:string" minOccurs="0"/>



</xs:sequence>

</xs:complexType>

<xs:complexType name="registrationASInfoType">

<xs:sequence>

<xs:element name="synchronizedReserve" type="xs:boolean" minOccurs="0"/>

<xs:element name="scheduledReserve" type="xs:boolean" minOccurs="0"/>

<xs:element name="regulation" type="xs:boolean" minOccurs="0"/>

<xs:element name="batchLoad" type="xs:boolean" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="registrationCapacityType">

<xs:sequence>

<xs:element name="capacityType" type="xs:string" minOccurs="0"/>

<xs:element name="longLeadTime" type="xs:boolean" minOccurs="0"/>

<xs:element name="zoneArea" type="xs:string" minOccurs="0"/>

<xs:element name="RPMResourceID" type="objectId" minOccurs="0"/>

<xs:element name="measurementMethod" type="xs:string" minOccurs="0"/>



<xs:element name="managedLoad" type="xs:double" minOccurs="0"/>

<xs:element name="multiplier" type="xs:double" minOccurs="0"/>

<xs:element name="nominalICAP" type="xs:double" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="registrationOtherType">

<xs:sequence>

<xs:element name="allowEDCtoModify" type="xs:boolean" minOccurs="0"/>

<xs:element name="allowLSEtoModify" type="xs:boolean" minOccurs="0"/>

<xs:element name="holdScheduling" type="xs:boolean" minOccurs="0"/>

<xs:element name="holdSettlements" type="xs:boolean" minOccurs="0"/>

<xs:element name="comment" type="xs:string" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:element name="Registration">

<xs:annotation>

<xs:documentation>LRS Registration Object</xs:documentation>

</xs:annotation>



<xs:complexType>

<xs:sequence>


<xs:element name="summaryInfo" type="registrationSummaryType" minOccurs="0"/>

<xs:element name="locationInfo" type="registrationLocationType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="energyInfo" type="registrationEnergyType" minOccurs="0"/>

<xs:element name="ASInfo" type="registrationASInfoType" minOccurs="0"/>

<xs:element name="capacityInfo" type="registrationCapacityType" minOccurs="0"/>

<xs:element name="otherInfo" type="registrationOtherType" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

LRSEvent.xsd <?xml version="1.0" encoding="UTF-8"?>





<xs:element name="Events">

<xs:complexType>

<xs:sequence>

<xs:element ref="Event" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:complexType name="eventSummaryType">

<xs:sequence>

<xs:element name="eventDate" type="xs:date" minOccurs="0"/>

<xs:element name="eventType" type="xs:string" minOccurs="0"/>

<xs:element name="startTime" type="xs:dateTime" minOccurs="0"/>

<xs:element name="endTime" type="xs:dateTime" minOccurs="0"/>

<xs:element name="description" type="xs:string" minOccurs="0"/>

<xs:element name="shortLead" type="xs:boolean" minOccurs="0"/>

<xs:element name="longLead" type="xs:boolean" minOccurs="0"/>




</xs:sequence>

</xs:complexType>

<xs:complexType name="zoneInfoType">

<xs:sequence>


</xs:sequence>

</xs:complexType>

<xs:complexType name="eventRegistrationType">

<xs:sequence>

<xs:element name="registrationId" type="objectId" minOccurs="0"/>









</xs:sequence>

</xs:complexType>

<xs:element name="Event">

<xs:annotation>

<xs:documentation>LRS Event object</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>


<xs:element name="summaryInfo" type="eventSummaryType" minOccurs="0"/>

<xs:element name="zoneInfo" type="zoneInfoType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="registrationInfo" type="eventRegistrationType" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

LRSSettlement.xsd








<xs:element name="Settlements">

<xs:complexType>

<xs:sequence>

<xs:element ref="Settlement" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:complexType name="settlementSummaryType">

<xs:sequence>

<xs:element name="referenceId" type="objectId" minOccurs="0"/>

<xs:element name="eventDate" type="xs:date" minOccurs="0"/>

<xs:element name="settlementType" type="xs:string" minOccurs="0"/>

<xs:element name="complianceOnly" type="xs:boolean" minOccurs="0"/>

<xs:element name="startTime" type="xs:dateTime" minOccurs="0"/>

<xs:element name="endTime" type="xs:dateTime" minOccurs="0"/>

<xs:element name="CBLMethod" type="xs:string" minOccurs="0"/>

<xs:element name="billDate" type="xs:date" minOccurs="0"/>

<xs:element name="adjustment" type="xs:boolean" minOccurs="0"/>


</xs:sequence>

</xs:complexType>

<xs:complexType name="settlementRegistrationType">

<xs:sequence>












</xs:sequence>

</xs:complexType>

<xs:complexType name="settlementInfoType">

<xs:sequence>

<xs:element name="eventHour" type="xs:integer" minOccurs="0"/>

<xs:element name="GMTHour" type="xs:dateTime" minOccurs="0"/>

<xs:element name="reductionHour" type="xs:boolean" minOccurs="0"/>

<xs:element name="marketType" type="xs:string" minOccurs="0"/>

<xs:element name="baseline" type="xs:double" minOccurs="0"/>

<xs:element name="load" type="xs:double" minOccurs="0"/>

<xs:element name="reduction" type="xs:double" minOccurs="0"/>

<xs:element name="rate" type="xs:double" minOccurs="0"/>

<xs:element name="lossFactor" type="xs:double" minOccurs="0"/>

<xs:element name="scheduled" type="xs:double" minOccurs="0"/>

<xs:element name="dispatched" type="xs:double" minOccurs="0"/>

<xs:element name="DAPrice" type="xs:double" minOccurs="0"/>

<xs:element name="RTPrice" type="xs:double" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="settlementTotalInfoType">

<xs:sequence>

<xs:element name="totalReduction" type="xs:double" minOccurs="0"/>

<xs:element name="averageRate" type="xs:double" minOccurs="0"/>

<xs:element name="averageLoss" type="xs:double" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="settlementOtherInfoType">

<xs:sequence>

<xs:element name="allowEDCtoModify" type="xs:boolean" minOccurs="0"/>

<xs:element name="allowLSEtoModify" type="xs:boolean" minOccurs="0"/>

<xs:element name="comment" type="xs:string" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:element name="Settlement">

<xs:annotation>

<xs:documentation>LRS Settlement Object</xs:documentation>

</xs:annotation>



<xs:complexType>

<xs:sequence>


<xs:element name="summaryInfo" type="settlementSummaryType" minOccurs="0"/>

<xs:element name="registrationInfo" type="settlementRegistrationType" minOccurs="0"/>

<xs:element name="settlementInfo" type="settlementInfoType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="totalInfo" type="settlementTotalInfoType" minOccurs="0"/>

<xs:element name="otherInfo" type="settlementOtherInfoType" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

LRSProcess.xsd: <?xml version="1.0" encoding="UTF-8"?>





<xs:element name="Processes">

<xs:complexType>

<xs:sequence>

<xs:element ref="Process" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:complexType name="processSummaryType">

<xs:sequence>

<xs:element name="processName" type="xs:string" minOccurs="0"/>

<xs:element name="processOwner" type="xs:string" minOccurs="0"/>

<xs:element name="startDate" type="xs:date" minOccurs="0"/>

<xs:element name="endDate" type="xs:date" minOccurs="0"/>


<xs:element name="objectID" type="objectId" minOccurs="0"/>

<xs:element name="objectType" type="xs:string" minOccurs="0"/>

</xs:sequence>



</xs:complexType>

<xs:complexType name="taskInfoType">

<xs:sequence>

<xs:element name="taskName" type="xs:string" minOccurs="0"/>

<xs:element name="taskOrg" type="xs:string" minOccurs="0"/>

<xs:element name="taskUser" type="xs:string" minOccurs="0"/>

<xs:element name="taskPriority" type="xs:string" minOccurs="0"/>

<xs:element name="taskStarted" type="xs:date" minOccurs="0"/>

<xs:element name="taskDue" type="xs:date" minOccurs="0"/>

<xs:element name="taskCompleted" type="xs:date" minOccurs="0"/>

<xs:element name="taskStatus" type="xs:string" minOccurs="0"/>

<xs:element name="reasons" type="xs:string" minOccurs="0"/>

<xs:element name="comments" type="xs:string" minOccurs="0"/>

<xs:element name="decisionInfo" type="decisionInfoType" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="decisionInfoType">

<xs:sequence>

<xs:element name="decisionName" type="xs:string" minOccurs="0"/>

<xs:element name="decisionReasons" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="attributeInfoType">

<xs:sequence>

<xs:element name="attribute" type="xs:string" minOccurs="0"/>

<xs:element name="attributeType" type="xs:string" minOccurs="0"/>

<xs:element name="initialValue" type="xs:string" minOccurs="0"/>

<xs:element name="value" type="xs:string" minOccurs="0"/>

<xs:element name="readOnly" type="xs:boolean" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:element name="Process">

<xs:annotation>

<xs:documentation>LRS CBL Object</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>




<xs:element name="summaryInfo" type="processSummaryType" minOccurs="0"/>

<xs:element name="taskInfo" type="taskInfoType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="attributeInfo" type="attributeInfoType" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

LRSDailyData.xsd <?xml version="1.0" encoding="UTF-8"?>





<xs:element name="DailysData">

<xs:complexType>

<xs:sequence>

<xs:element ref="DailyData" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:complexType name="dailySummaryType">

<xs:sequence>

<xs:element name="locationId" type="objectId" minOccurs="0"/>



</xs:sequence>

</xs:complexType>

<xs:complexType name="dailyMeasurementInfoType">

<xs:sequence>

<xs:element name="dateStamp" type="xs:date" minOccurs="0"/>


<xs:element name="UOM" type="xs:string" minOccurs="0"/>

<xs:element name="intervals" type="xs:integer" minOccurs="0"/>

<xs:element name="values" type="listOfValues" minOccurs="0"/>

<xs:element name="latest" type="xs:boolean" minOccurs="0"/>



<xs:element name="submittedBy" type="xs:string" minOccurs="0"/>

<xs:element name="submittedate" type="xs:dateTime" minOccurs="0"/>

<xs:element name="submissionError" type="xs:string" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:element name="DailyData">

<xs:annotation>

<xs:documentation>Daily Data Object</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>

<xs:element name="summaryInfo" type="dailySummaryType" minOccurs="0"/>

<xs:element name="measurementInfo" type="dailyMeasurementInfoType" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

LRSIntervalData.xsd <?xml version="1.0" encoding="UTF-8"?>





<xs:element name="IntervalsData">

<xs:complexType>

<xs:sequence>

<xs:element ref="IntervalData" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:complexType name="intervalDataSummaryType">

<xs:sequence>

<xs:element name="locationId" type="objectId" minOccurs="0"/>



</xs:sequence>



</xs:complexType>

<xs:complexType name="intervalMeasurementInfoType">

<xs:sequence>

<xs:element name="timestamp" type="xs:dateTime" minOccurs="0"/>


<xs:element name="UOM" type="xs:string" minOccurs="0"/>

<xs:element name="value" type="xs:double" minOccurs="0"/>

<xs:element name="latest" type="xs:boolean" minOccurs="0"/>

<xs:element name="submittedBy" type="xs:string" minOccurs="0"/>

<xs:element name="submittedDate" type="xs:dateTime" minOccurs="0"/>

<xs:element name="submissionError" type="xs:string" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:element name="IntervalData">

<xs:annotation>

<xs:documentation>Interval Data Object</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>

<xs:element name="summaryInfo" type="intervalDataSummaryType" minOccurs="0"/>

<xs:element name="measurementInfo" type="intervalMeasurementInfoType" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

LRSAlert.xsd <?xml version="1.0" encoding="UTF-8"?>




<xs:complexType name="AlertMessageType">

<xs:sequence>

<xs:element name="subject" type="xs:string"></xs:element>

<xs:element name="message" type="xs:string"></xs:element>

<xs:element name="objectType" type="xs:string"></xs:element>



<xs:element name="objectId" type="objectId"></xs:element>

<xs:element name="expirationDate" type="xs:date"></xs:element>

<xs:element name="urgent" type="xs:boolean"></xs:element>

</xs:sequence>

</xs:complexType>

<xs:element name="Alerts">

<xs:complexType>

<xs:sequence>

<xs:element name="Alert" type="AlertMessageType" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

Appendix C: Payload Compression Example The purpose of this section is to provide an example of the code required to compress and encode a payload, where the payload is then

passed as the contents of the Payload/Compressed element. The following is a Java example that leverages commonly used classes for

compression and base64 encoding.

package BusinessService.TS.WebServiceClient.CompressionClient;

import java.util.*;

import java.io.*;

import java.io.File;

import java.io.FileInputStream;

import java.io.FileOutputStream;

import java.io.InputStream;

import java.io.IOException;

import java.util.zip.*;

import org.apache.soap.encoding.soapenc.Base64;

public class CompressionClientCompressandEncode{

protected byte[] input = null;

protected String base64GzipInput = "";

public byte[] getinput() { return input; }

public void setinput(byte[] val) { input = val; }

public String getbase64GzipInput() { return base64GzipInput; }

public void setbase64GzipInput(String val) { base64GzipInput = val; }



public CompressionClientCompressandEncode() { }

public void invoke() throws Exception {

In : byte[] input

Out : String base64GzipInput

ByteArrayOutputStream bas = new ByteArrayOutputStream();

GZIPOutputStream bis = new GZIPOutputStream(bas);

bis.write(input);

bis.close();

base64GzipInput = Base64.encode(bas.toByteArray());

}

}

Lrs External Web Services Specifications PDF

Documents

Transcript of Lrs External Web Services Specifications PDF