SPP External Interface Specification Market Participant XML 36 - mui xml interface... · 9 2.1...

SPP External Interface Specification Market Participant XML

This document describes the SPP MUI External XML interface.

Please see the version 32 36 revision history entry for details on what changes have been introduced in this release of the document. Corresponding XML Schema (spp_emkt.xsd) Version: 2427

Date: March June 228, 2011 Version: 3336.0 Transmittal No.: 1007E0048.3336

AREVA Corporation Redmond, Washington USA

Copyright and Proprietary Information

Copyright © 2003, 2008 AREVA T&D INC. All Rights Reserved.

NOTE: CONTAINS AREVA T&D INC. PROPRIETARY INFORMATION. DO NOT COPY, STORE IN A RETRIEVAL SYSTEM, TRANSMIT OR DISCLOSE TO ANY THIRD PARTY WITHOUT THE PRIOR WRITTEN PERMISSION FROM AN OFFICER OF AREVA T&D INC.

Trademarks

“ESCA” and “HABITAT” are registered trademarks of AREVA T&D Inc. “e-terra” is a registered trademark and/or service mark of E-Terra, LLC, licensed for use by AREVA T&D Inc in connection with its e-terra family of products and services.

Other product and company names in these materials may be trademarks or registered trademarks of other companies, and are the property of their respective owners. They are used only for explanation and to the respective owners’ benefit, without intent to infringe.

SPP External Interface Specification, Ver. 362.0 Copyright © 2003, 2008 2011 AREVA T&D Inc. All Rights Reserved.

iv

Table of Contents

1. Introduction............................................................................................. 1

1.1 Purpose ..................................................................................................................... 1 1.2 Technology Prerequisite Knowledge ......................................................................... 2 1.3 Document References ............................................................................................... 2 1.4 Terminology ............................................................................................................... 3

2. External Interface Data Exchange Overview ........................................ 9

2.1 Market Participants .................................................................................................... 9 2.2 Submitted Data .......................................................................................................... 9 2.3 Notification Data ........................................................................................................ 9 2.4 Query Data .............................................................................................................. 10 2.5 Day-ahead and Real-time Operation Timeline ........................................................ 11

3. Introduction to the Programmatic API ................................................ 12

3.1 Messaging Overview ............................................................................................... 12 3.1.1 Participant Roles ................................................................................................ 12

3.2 Request/Reply Messaging ....................................................................................... 12 3.3 Push (Asynchronous) Messaging ............................................................................ 14 3.4 XML File Upload and Download .............................................................................. 16 3.5 Web Technologies ................................................................................................... 16

3.5.1 XML – Extensible Markup Language ................................................................. 17 3.5.2 SOAP – A Web Services API ............................................................................. 19 3.5.3 HTTP/HTTPS ..................................................................................................... 19 3.5.4 SSL and Authentication ...................................................................................... 20 3.5.5 Digital Certificates .............................................................................................. 20

4. Common Principles .............................................................................. 22

4.1 Participant Registration ........................................................................................... 22 4.2 SPP Server Addressing ........................................................................................... 22 4.3 HTTP Command and Headers ................................................................................ 23

4.3.1 HTTP Request Message Format ....................................................................... 23 4.3.2 HTTP Response (reply) Message Format ......................................................... 25

4.4 SOAP Envelope ....................................................................................................... 26 4.5 XML Namespaces ................................................................................................... 28 4.6 XML Schema ........................................................................................................... 30 4.7 Error Response ........................................................................................................ 30 4.8 Transaction Semantics ............................................................................................ 32

4.8.1 Transaction Semantics and Transaction Identifier ............................................. 32


v

4.8.2 Transaction Log .................................................................................................. 32 4.9 XML Data Type and Specification Semantics ......................................................... 33

4.9.1 Character Case .................................................................................................. 33 4.9.2 XML Boolean Data ............................................................................................. 33 4.9.3 XML Date and Time ........................................................................................... 34 4.9.4 XML Character Data, Markup, and Escaped Characters .................................. 37 4.9.5 XML Null Data .................................................................................................... 38 4.9.6 XML Absent Elements ........................................................................................ 39 4.9.7 XML Attribute and Element Ordering ................................................................. 39 4.9.8 Common Data Types ......................................................................................... 39

4.10 File Upload/Download Format ............................................................................... 43

5. Data Submittal, Update, Delete ........................................................... 45

5.1 Data Submit Overview ............................................................................................. 46 5.1.1 SubmitRequest Message ................................................................................... 46

5.2 Submitting Ancillary Service Capacity Plan ............................................................ 48 5.2.1 Submit Description ............................................................................................. 49 5.2.2 Replace and Delete Description ......................................................................... 50

5.3 Submitting Energy Imbalance Service Offer ........................................................... 51 5.3.1 Submit Description ............................................................................................. 52 5.3.2 Replace and Delete Description ......................................................................... 52

5.4 Submitting Resource Plan ....................................................................................... 53 5.4.1 Submit Description ............................................................................................. 54 5.4.2 Replace Description ........................................................................................... 55

5.5 Submitting Participant Load Forecast ..................................................................... 56 5.5.1 Submit Description ............................................................................................. 57 5.5.2 Replace and Delete Description ......................................................................... 58

6. Notification Messages .......................................................................... 59

6.1 Notifications Overview ............................................................................................. 61 6.1.1 Notifications Messaging ..................................................................................... 61 6.1.2 Listening For Notification Messages .................................................................. 63 6.1.3 Multiple Notifications Listeners ........................................................................... 65 6.1.4 Notifications Retry .............................................................................................. 66

6.2 Notification Message Schema Template ................................................................. 66 6.3 Ping Notification Message ....................................................................................... 68

7. Data Query ............................................................................................ 70

7.1 Query Overview ....................................................................................................... 75 7.1.1 Query Request and Reply Semantics ................................................................ 75

7.2 Query ASCapacityObligation ................................................................................... 78 7.2.1 Query Description ............................................................................................... 78


vi

7.2.2 Query Schema Template ................................................................................... 78 7.2.3 Query Data Description ...................................................................................... 78 7.2.4 Availability ........................................................................................................... 79 7.2.5 Query Results ..................................................................................................... 79 7.2.6 Query Examples ................................................................................................. 79

7.3 Query ASCapacityPlan ............................................................................................ 79 7.3.1 Query Description ............................................................................................... 80 7.3.2 Query Schema Template ................................................................................... 80 7.3.3 Query Data Description ...................................................................................... 80 7.3.4 Availability ........................................................................................................... 81 7.3.5 Query Results ..................................................................................................... 81 7.3.6 Query Examples ................................................................................................. 81

7.4 Query CalculatedCurtailmentLevel .......................................................................... 82 7.4.1 Query Description ............................................................................................... 82 7.4.2 Query Schema Template ................................................................................... 83 7.4.3 Query Data Description ...................................................................................... 83 7.4.4 Availability ........................................................................................................... 84 7.4.5 Query Results ..................................................................................................... 84 7.4.6 Query Examples ................................................................................................. 84

7.5 Query Current EISOffer Cap ................................................................................... 84 7.5.1 Query Description ............................................................................................... 84 7.5.2 Query Schema Template ................................................................................... 85 7.5.3 Query Data Description ...................................................................................... 85 7.5.4 Availability ........................................................................................................... 85 7.5.5 Query Results ..................................................................................................... 85 7.5.6 Query Examples ................................................................................................. 85

7.6 Query All Current EISOffer Cap .............................................................................. 86 7.6.1 Query Description ............................................................................................... 86 7.6.2 Query Schema Template ................................................................................... 86 7.6.3 Query Data Description ...................................................................................... 86 7.6.4 Query Results ..................................................................................................... 86 7.6.5 Query Examples ................................................................................................. 87

7.7 Query Current URD Resource Locked .................................................................... 87 7.7.1 Query Description ............................................................................................... 87 7.7.2 Query Schema Template ................................................................................... 87 7.7.3 Query Data Description ...................................................................................... 88 7.7.4 Availability ........................................................................................................... 88 7.7.5 Query Results ..................................................................................................... 88 7.7.6 Query Examples ................................................................................................. 88

7.8 Query All Current URD Resource Locked ............................................................... 89 7.8.1 Query Description ............................................................................................... 89 7.8.2 Query Schema Template ................................................................................... 89 7.8.3 Query Data Description ...................................................................................... 89 7.8.4 Query Results ..................................................................................................... 89 7.8.5 Query Examples ................................................................................................. 90

7.9 Query DeliverabilityAnalysis .................................................................................... 90


vii

7.9.1 Query Description ............................................................................................... 90 7.9.2 Query Schema Template ................................................................................... 91 7.9.3 Query Data Description ...................................................................................... 91 7.9.4 Availability ........................................................................................................... 92 7.9.5 Query Results ..................................................................................................... 92 7.9.6 Query Examples ................................................................................................. 92

7.10 Query Dispatch ...................................................................................................... 97 7.10.1 Query Description ............................................................................................. 97 7.10.2 Query Schema Template ................................................................................. 97 7.10.3 Query Data Description .................................................................................... 97 7.10.4 Availability ......................................................................................................... 98 7.10.5 Query Results ................................................................................................... 99 7.10.6 Query Examples ............................................................................................... 99

7.11 Query All Dispatch ............................................................................................... 100 7.11.1 Query Description ........................................................................................... 100 7.11.2 Query Schema Template ............................................................................... 100 7.11.3 Query Data Description .................................................................................. 100 7.11.4 Query Results ................................................................................................. 101 7.11.5 Query Examples ............................................................................................. 101

7.12 Query EISOffer .................................................................................................... 102 7.12.1 Query Description ........................................................................................... 102 7.12.2 Query Schema Template ............................................................................... 102 7.12.3 Query Data Description .................................................................................. 102 7.12.4 Availability ....................................................................................................... 103 7.12.5 Query Results ................................................................................................. 103 7.12.6 Query Examples ............................................................................................. 103

7.13 Query All EISOffer ............................................................................................... 104 7.13.1 Query Description ........................................................................................... 104 7.13.2 Query Schema Template ............................................................................... 105 7.13.3 Query Data Description .................................................................................. 105 7.13.4 Query Results ................................................................................................. 105 7.13.5 Query Examples ............................................................................................. 105

7.14 Query EnergyLMP ............................................................................................... 106 7.14.1 Query Description ........................................................................................... 106 7.14.2 Query Schema Template ............................................................................... 106 7.14.3 Query Data Description .................................................................................. 106 7.14.4 Availability ....................................................................................................... 107 7.14.5 Query Results ................................................................................................. 107 7.14.6 Query Examples ............................................................................................. 107

7.15 Query All Energy LMP ......................................................................................... 109 7.15.1 Query Description ........................................................................................... 109 7.15.2 Query Schema Template ............................................................................... 109 7.15.3 Query Data Description .................................................................................. 109 7.15.4 Query Results ................................................................................................. 110 7.15.5 Query Examples ............................................................................................. 110

7.16 Query InvalidResourcePlan ................................................................................. 111


viii

7.16.1 Query Description ........................................................................................... 111 7.16.2 Query Schema Template ............................................................................... 111 7.16.3 Query Data Description .................................................................................. 111 7.16.4 Availability ....................................................................................................... 111 7.16.5 Query Results ................................................................................................. 112 7.16.6 Query Examples ............................................................................................. 112

7.17 Query MarketSchedule ........................................................................................ 112 7.17.1 Query Description ........................................................................................... 112 7.17.2 Query Schema Template ............................................................................... 112 7.17.3 Query Data Description .................................................................................. 113 7.17.4 Availability ....................................................................................................... 113 7.17.5 Query Results ................................................................................................. 113

7.18 Query MidtermLoadForecast ............................................................................... 113 7.18.1 Query Description ........................................................................................... 113 7.18.2 Query Schema Template ............................................................................... 114 7.18.3 Query Data Description .................................................................................. 114 7.18.4 Availability ....................................................................................................... 115 7.18.5 Query Results ................................................................................................. 115 7.18.6 Query Examples ............................................................................................. 115

7.19 Query MismatchASCapacityPlan ........................................................................ 117 7.19.1 Query Description ........................................................................................... 117 7.19.2 Query Schema Template ............................................................................... 117 7.19.3 Query Data Description .................................................................................. 117 7.19.4 Availability ....................................................................................................... 117 7.19.5 Query Results ................................................................................................. 118 7.19.6 Query Examples ............................................................................................. 118

7.20 Query OperatorMessage ..................................................................................... 118 7.20.1 Query Description ........................................................................................... 118 7.20.2 Query Schema Template ............................................................................... 119 7.20.3 Query Data Description .................................................................................. 119 7.20.4 Availability ....................................................................................................... 119 7.20.5 Query Results ................................................................................................. 119 7.20.6 Query Examples ............................................................................................. 119

7.21 Query OperatorOverride ...................................................................................... 120 7.21.1 Query Description ........................................................................................... 120 7.21.2 Query Schema Template ............................................................................... 120 7.21.3 Query Data Description .................................................................................. 120 7.21.4 Availability ....................................................................................................... 121 7.21.5 Query Results ................................................................................................. 121 7.21.6 Query Examples ............................................................................................. 121

7.22 Query OverUnderCommitment ............................................................................ 122 7.22.1 Query Description ........................................................................................... 122 7.22.2 Query Schema Template ............................................................................... 122 7.22.3 Query Data Description .................................................................................. 123 7.22.4 Availability ....................................................................................................... 123 7.22.5 Query Results ................................................................................................. 124


ix

7.22.6 Query Examples ............................................................................................. 124 7.23 Query ParticipantLoadForecast ........................................................................... 125

7.23.1 Query Description ........................................................................................... 125 7.23.2 Query Schema Template ............................................................................... 125 7.23.3 Query Data Description .................................................................................. 125 7.23.4 Availability ....................................................................................................... 126 7.23.5 Query Results ................................................................................................. 126 7.23.6 Query Examples ............................................................................................. 126

7.24 Query ResourcePlan ........................................................................................... 127 7.24.1 Query Description ........................................................................................... 127 7.24.2 Query Schema Template ............................................................................... 127 7.24.3 Query Data Description .................................................................................. 127 7.24.4 Availability ....................................................................................................... 128 7.24.5 Query Results ................................................................................................. 128 7.24.6 Query Examples ............................................................................................. 128

7.25 Query Self Dispatch Max Violation ...................................................................... 129 7.25.1 Query Description ........................................................................................... 129 7.25.2 Query Schema Template ............................................................................... 129 7.25.3 Query Data Description .................................................................................. 130 7.25.4 Availability ....................................................................................................... 130 7.25.5 Query Results ................................................................................................. 130 7.25.6 Query Examples ............................................................................................. 130

7.26 Query All Self Dispatch Max Violation ................................................................. 131 7.26.1 Query Description ........................................................................................... 131 7.26.2 Query Schema Template ............................................................................... 131 7.26.3 Query Data Description .................................................................................. 131 7.26.4 Query Results ................................................................................................. 131 7.26.5 Query Examples ............................................................................................. 132

7.27 Query Self Dispatch Min Violation ....................................................................... 132 7.27.1 Query Description ........................................................................................... 132 7.27.2 Query Schema Template ............................................................................... 132 7.27.3 Query Data Description .................................................................................. 132 7.27.4 Availability ....................................................................................................... 133 7.27.5 Query Results ................................................................................................. 133 7.27.6 Query Examples ............................................................................................. 133

7.28 Query All Self Dispatch Min Violation .................................................................. 134 7.28.1 Query Description ........................................................................................... 134 7.28.2 Query Schema Template ............................................................................... 134 7.28.3 Query Data Description .................................................................................. 134 7.28.4 Query Results ................................................................................................. 134 7.28.5 Query Examples ............................................................................................. 134

7.29 Query ShorttermLoadForecast ............................................................................ 135 7.29.1 Query Description ........................................................................................... 135 7.29.2 Query Schema Template ............................................................................... 135 7.29.3 Query Data Description .................................................................................. 135 7.29.4 Availability ....................................................................................................... 136


x

7.29.5 Query Results ................................................................................................. 136 7.29.6 Query Examples ............................................................................................. 136

7.30 Query URD Interval ............................................................................................. 137 7.30.1 Query Description ........................................................................................... 137 7.30.2 Query Data Description .................................................................................. 137 7.30.3 Availability ....................................................................................................... 138 7.30.4 Query Results ................................................................................................. 139 7.30.5 Query Examples ............................................................................................. 139

7.31 Query All URD Interval ........................................................................................ 139 7.31.1 Query Description ........................................................................................... 139 7.31.2 Query Data Description .................................................................................. 140 7.31.3 Query Results ................................................................................................. 140 7.31.4 Query Examples ............................................................................................. 140

7.32 Query Violation Relaxation Limit ......................................................................... 141 7.32.1 Query Description ........................................................................................... 141 7.32.2 Query Data Description .................................................................................. 142 7.32.3 Query Results ................................................................................................. 143 7.32.4 Query Examples ............................................................................................. 143

8. Transaction Query .............................................................................. 145

8.1 Transactions Overview .......................................................................................... 145 8.2 Query By Transaction Identifier ............................................................................. 145

9. Message Catalog ................................................................................ 147

9.1 ASCapacityObligation ............................................................................................ 147 9.1.1 Description ........................................................................................................ 147 9.1.2 Schema Template ............................................................................................ 147 9.1.3 Data Description ............................................................................................... 147 9.1.4 Example ............................................................................................................ 149

9.2 ASCapacityPlan ..................................................................................................... 149 9.2.1 Description ........................................................................................................ 149 9.2.2 Schema Template ............................................................................................ 150 9.2.3 Data Description ............................................................................................... 150 9.2.4 Example ............................................................................................................ 152

9.3 CalculatedCurtailmentLevel................................................................................... 152 9.3.1 Description ........................................................................................................ 152 9.3.2 Schema Template ............................................................................................ 153 9.3.3 Data Description ............................................................................................... 153 9.3.4 Example ............................................................................................................ 154

9.4 CurrentEISOfferCap .............................................................................................. 155 9.4.1 Description ........................................................................................................ 155 9.4.2 Schema Template ............................................................................................ 155 9.4.3 Data Description ............................................................................................... 155 9.4.4 Example ............................................................................................................ 156


xi

9.5 CurrentURDResourceLocked ................................................................................ 156 9.5.1 Description ........................................................................................................ 156 9.5.2 Schema Template ............................................................................................ 156 9.5.3 Data Description ............................................................................................... 156 9.5.4 Example ............................................................................................................ 158

9.6 DeliverabilityAnalysis ............................................................................................. 158 9.6.1 Description ........................................................................................................ 158 9.6.2 Schema Template ............................................................................................ 160 9.6.3 Data Description ............................................................................................... 160 9.6.4 Example ............................................................................................................ 162

9.7 Dispatch ................................................................................................................. 162 9.7.1 Description ........................................................................................................ 162 9.7.2 Schema Template ............................................................................................ 163 9.7.3 Data Description ............................................................................................... 163 9.7.4 Example ............................................................................................................ 164

9.8 EISOffer ................................................................................................................. 165 9.8.1 Description ........................................................................................................ 165 9.8.2 Schema Template ............................................................................................ 165 9.8.3 Data Description ............................................................................................... 165 9.8.4 Example ............................................................................................................ 167

9.9 EISOfferCap .......................................................................................................... 167 9.9.1 Description ........................................................................................................ 167 9.9.2 Schema Template ............................................................................................ 168 9.9.3 Data Description ............................................................................................... 168 9.9.4 Example ............................................................................................................ 168

9.10 EISOfferCapEnabled ........................................................................................... 169 9.10.1 Description ...................................................................................................... 169 9.10.2 Schema Template .......................................................................................... 169 9.10.3 Data Description ............................................................................................. 169 9.10.4 Example .......................................................................................................... 170

9.11 EISOfferCapDisabled .......................................................................................... 170 9.11.1 Description ...................................................................................................... 170 9.11.2 Schema Template .......................................................................................... 171 9.11.3 Data Description ............................................................................................. 171 9.11.4 Example .......................................................................................................... 172

9.12 EnergyLMP .......................................................................................................... 172 9.12.1 Description ...................................................................................................... 172 9.12.2 Schema Template .......................................................................................... 172 9.12.3 Data Description ............................................................................................. 173 9.12.4 Example .......................................................................................................... 174

9.13 InvalidResourcePlan ............................................................................................ 174 9.13.1 Description ...................................................................................................... 174 9.13.2 Schema Template .......................................................................................... 175 9.13.3 Data Description ............................................................................................. 175 9.13.4 Example .......................................................................................................... 176

9.14 MarketSchedule ................................................................................................... 176


xii

9.14.1 Description ...................................................................................................... 176 9.14.2 Schema Template .......................................................................................... 178 9.14.3 Data Description ............................................................................................. 178 9.14.4 Example .......................................................................................................... 179

9.15 MidtermLoadForecast .......................................................................................... 179 9.15.1 Description ...................................................................................................... 179 9.15.2 Schema Template .......................................................................................... 179 9.15.3 Data Description ............................................................................................. 179 9.15.4 Example .......................................................................................................... 180

9.16 MismatchASCapacityPlan ................................................................................... 181 9.16.1 Description ...................................................................................................... 181 9.16.2 Schema Template .......................................................................................... 182 9.16.3 Data Description ............................................................................................. 182 9.16.4 Example .......................................................................................................... 183

9.17 OperatorMessage ................................................................................................ 183 9.17.1 Description ...................................................................................................... 183 9.17.2 Schema Template .......................................................................................... 184 9.17.3 Data Description ............................................................................................. 184 9.17.4 Example .......................................................................................................... 185

9.18 OperatorOverride ................................................................................................. 185 9.18.1 Description ...................................................................................................... 185 9.18.2 Schema Template .......................................................................................... 185 9.18.3 Data Description ............................................................................................. 185 9.18.4 Example .......................................................................................................... 186

9.19 OverUnderCommitment ....................................................................................... 186 9.19.1 Description ...................................................................................................... 186 9.19.2 Schema Template .......................................................................................... 188 9.19.3 Data Description ............................................................................................. 188 9.19.4 Example .......................................................................................................... 190

9.20 ParticipantLoadForecast ...................................................................................... 191 9.20.1 Description ...................................................................................................... 191 9.20.2 Schema Template .......................................................................................... 191 9.20.3 Data Description ............................................................................................. 191 9.20.4 Example .......................................................................................................... 192

9.21 Ping ...................................................................................................................... 193 9.21.1 Description ...................................................................................................... 193 9.21.2 Schema Template .......................................................................................... 193 9.21.3 Data Description ............................................................................................. 193 9.21.4 Example .......................................................................................................... 193

9.22 ResourcePlan ...................................................................................................... 194 9.22.1 Description ...................................................................................................... 194 9.22.2 Schema Template .......................................................................................... 197 9.22.3 Data Description ............................................................................................. 197 9.22.4 Example .......................................................................................................... 199

9.23 SelfDispatchMaxViolation .................................................................................... 201 9.23.1 Description ...................................................................................................... 201


xiii

9.23.2 Schema Template .......................................................................................... 201 9.23.3 Data Description ............................................................................................. 201 9.23.4 Example .......................................................................................................... 202

9.24 SelfDispatchMinViolation ..................................................................................... 203 9.24.1 Description ...................................................................................................... 203 9.24.2 Schema Template .......................................................................................... 203 9.24.3 Data Description ............................................................................................. 203 9.24.4 Example .......................................................................................................... 204

9.25 ShorttermLoadForecast ....................................................................................... 205 9.25.1 Description ...................................................................................................... 205 9.25.2 Schema Template .......................................................................................... 205 9.25.3 Data Description ............................................................................................. 205 9.25.4 Example .......................................................................................................... 206

9.26 URDInterval ......................................................................................................... 207 9.26.1 Description ...................................................................................................... 207 9.26.2 Schema Template .......................................................................................... 207 9.26.3 Data Description ............................................................................................. 208 9.26.4 Example .......................................................................................................... 210

9.27 URDResourceLocked .......................................................................................... 210 9.27.1 Description ...................................................................................................... 210 9.27.2 Schema Template .......................................................................................... 211 9.27.3 Data Description ............................................................................................. 211 9.27.4 Example .......................................................................................................... 212

9.28 ReturningURDLockedResource .......................................................................... 213 9.28.1 Description ...................................................................................................... 213 9.28.2 Schema Template .......................................................................................... 213 9.28.3 Data Description ............................................................................................. 213 9.28.4 Example .......................................................................................................... 214

9.29 URDResourceUnlocked ...................................................................................... 215 9.29.1 Description ...................................................................................................... 215 9.29.2 Schema Template .......................................................................................... 215 9.29.3 Data Description ............................................................................................. 215 9.29.4 Example .......................................................................................................... 216

9.30 ViolationRelaxationLimit ...................................................................................... 217 9.30.1 Description ...................................................................................................... 217 9.30.2 Schema Template .......................................................................................... 217 9.30.3 Data Description ............................................................................................. 218 9.30.4 Example .......................................................................................................... 220


xiv

About This Document Purpose of This Document

The purpose of this document is to describe the participant’s XML-based external interface to the SPP Market Operations System (MOS).

Who Should Use This Document This document is intended to be a reference / specification document for SPP and Market Participants who interface with the market system using XML

Structure of This Document An introduction chapter is provided to describe XML principles and the basic details of the implementation.

This is followed by details of each XML data submittal, notification, query, and message.

Change Summary Ver #

Transmittal Date Comments

1 877E0006 12/8/03 [peh] Original Draft. 2 1007E0008 5/17/04 [peh] Updated After Project Start with following

changes: Changed occurrences of ASE to TC for Transmission Customer. These changes are not under tracking control due to the simplicity of the change and the large number of changes in the document. Additions of message types that were previously undocumented because they were part of the Increment 3 release which has since been folded into the project schedule. Changes to the previous message formats because the earlier message types proved to be confusing or problematic with respect to the corresponding displays.

3 1007E0008.2 8/11/04 [peh] Updated after review of Rev. 2 by customer. Changes also reflect major differences in current requirements versus Rev 2 original requirements (e.g. such as no longer a day-ahead market for ancillary service


xv

Ver #


capacity). All changes are shown and marked by change bars. Major changes to the specification with Revision 3 are: Updated to reflect the removal of message types due to the fact that the ancillary service day-ahead market will not exist in this phase of the system. This action removed the message types: ASCapacityAward, ASCapacityOffer, ASCapacityRequirement, MCPC. Updated the message descriptions (primarily in the Message Catalog chapter) to reflect minor changes resulting from testing and integration with the database as well as refinements in the requirements. Greatly expanded the content of the Data submittal chapter to describe the submittal in detail for each message type and to give examples of replacement and delete. Greatly expanded the Data Query chapter giving detailed descriptions of every query request and examples of usage.

4 1007E0008.3 8/25/04 [peh] Updated after review of Rev. 3 by customer and other changes demanded by new requests from customer. [cgj] Added cross-reference to XML Schema Revision 4 on title page. [ahb] Added SPIN and SUPP to list of valid product codes. [ahb] removed reference to “regulation obligation” in description of AS product code

5 1007E0008.4 9/24/04 [peh/cgj] Updated after review of Rev. 4 by customer and internal review by cgj, and to reflect XML schema changes. Added OperatorOverride message. Consolidated EISDispatch and OOMEDispatch into Dispatch message. Replaced Area with ControlArea or LoadArea. Changed “AS” to “ancillary service”. Completed some previously missing business rule and data type descriptions. Corrected some examples to correspond to the schema. Miscellaneous cleanup.


xvi

Ver #


6 1007E0048.1 10/15/04 [cgj] Updated after review of Rev. 5 by customer. Removed references to day-ahead market. Clarified some common data type definitions. Changed ASCapacityPlan example. Replaced LastForecastMW with ForecastTime. Deleted Section 10, Cross Reference: OLD and NEW XML Formats.

7 <TBD> 12/22/04 [cgj] Updated to state that MW values on EIS Offers must be nonnegative. Ref. issue PJ12383.

7.1 <TBD> 1/27/05 [tga] Update formatting to standard. 7.2 <TBD> 2/09/05 [ahb] Changed STLF interval to 5 minutes.

Added some more clarification to the MarketSchedule message description. Corrected submission deadlines for EIS Offers. Changed Operator Override query description to reflect new behaviors. Removed reference to SOAP 1.2 as being under development.

7.3 <TBD> 2/10/05 [ahb] Added description of SOAP fault message

7.4 <TBD> 2/28/05 [ahb] Removed ambiguous language from EIS Offer submittal description

7.5 <TBD> 4/20/05 [ahb] Changed all references to MW to integers, and expanded MarketSchedule nominal event descriptions

7.6 <TBD> 5/18/05 [ahb] Corrected web service URLs and SOAP action references.

7.7 10070048.4 8/31/05 [ahb] Clarification of SOAP references and Web Services

7.8 <TBD> 7/20/05 [ahb] removed confusing and inaccurate language about SPP-distributed notification listener software and benchmarking requirements

7.9 <TBD> 7/28/05 [jzc] added EIS Offer Cap and URD Mitigation Notifications.

8.0 <TBD> 8/2/05 [ahb] added self dispatch violation messages and queries

8.1 <TBD> 9/7/05 [ahb] merged in changes based on SPP comments on version 7.6

9 1007E0048.9 9/8/05 [ahb] Edited based on SPP comments on version 8.0.


xvii

Ver #


10 1007E0048.10 9/29/05 [ahb] • Revised for Phase 2 business rule changes • Updated reference to market protocols

document • Changed all references to “TC” to “MP”

where applicable • Corrected typos in URD query and

Dispatch message XML examples • Added cross-reference links for

chapter/section references • Added footnotes where applicable

referencing market protocols document • Corrected case on some XML attribute

names in field description tables • Corrected numerous spelling and

grammatical errors 11.0 1007E0048.11 9/30/05 [ahb] Fixed additional upper/lower case typos

and other small items. 12.0 1007E0048.12 10/21/05 [ahb] Corrected interval examples during DST

in section 4.9.7. Repeated hour ending is 2, but the interior of the repeated hour is still 1. Expanded section 4.9.3 to highlight the repeating of hour ending 2:00:00.

13.0 1007E0048.13 11/4/05 [ahb] – Now describes xsd V11 • Changed LockBeginsDay,

LockBeginsInterval, LockExpiresDay, LockExpiresInterval elements in CurrentURDResourceLocked type to be optional as they will be null when the resource is not locked

• Changed instances of “true” and “false” to use the code sample style when referring to a value that might appear in XML

• Clarified confusing statement in isDuplicateHour attribute descriptions in Chapter 9 that seemed to say the attribute was optional unless required

• Added ReturningURDLockedResource message to replace usage of URDResourceLocked with “reminder=true”


xviii

Ver #


• Removed “reminder” attribute from URDResourceLocked

• Updated MarketSchedule description based on enhancements that changed its return values

• Cleaned up some vague language regarding XML and MP listeners

• Added note to section 5.1.1 regarding performance and message size.

14.0 1007E0048.14 1/30/06 [ahb] – Updated based on SPP comments: • Removed remaining instances of confusing

statement in isDuplicateHour attribute descriptions in Chapter 9 that seemed to say the attribute was optional unless required

• Corrected typo in section 2.3 “ReturtingURDLockedResource”

15.0 1007E0048.15 2/15/06 [ahb] – Updated based on SPP comments: • Clarified granularity at which notifications

messages can be expected to appear in section 6.2

• Added text to section 9.12 clarifying when MarketSchedule messages will be sent

• Clarified use of ApprovalTime and LIP fields in OOME dispatch in section 9.5

• Added GMT offsets and milliseconds to timestamps in XML examples

• Corrected a few attribute name case typos that had crept into some “data description” tables.

16.0 1007E0048.16 5/21/06 [ahb] – Added new message types: • <ParticipantLoadForecast> • <OverUnderCommitment> Modified QueryEnergyLMP to use Resource and ResourceType parameters rather than Location, and added QueryAllEnergyLMP to support query for all resources. Modified EnergyLMP to return Resource and ResourceType fields.


xix

Ver #


17.0 1007E0048.17 5/22/06 [ahb] • Corrected OverUnderCommitment

calculations and added fields for AS Scheduled Up/Down MW

• Modified QueryEnergyLMP to use Resource and ResourceType parameters rather than Location, and added QueryAllEnergyLMP to support query for all resources.

• Modified EnergyLMP to return Resource and ResourceType fields.

18.0 1007E0048.18 6/13/06 [ahb] • Changed Resource and ResourceType

fields in Query/EnergyLMP to SettlementLocation and SettlementLocationType.

• Changed Location field in EnergyLMP to Pnode

• Changed all sample XML entity names to more generic names

• Clarified language in 7.13.1 to state that Energy LMP is available for all locations regardless of ownership.

• Clarified language in 5.5.1 to state that ParticipantLoadForecast does not need to be submitted for 24 hours at a time

19.0 1007E0048.19 6/14/06 [ahb] • Corrected example description in section

5.5.1 plus some typos elsewhere. 20.0 1007E0048.20 6/26/06 [ahb]

• Changed URDIntervalViolation message and queries to URDInterval and added waiver and reason fields

• Added DeliverabilityAnalysis message and queries

• Corrected some casing issues on attribute names

• Changed all interval and hour examples to not be zero padded as they will not appear that way in XML returned from MUI


xx

Ver #


• Removed decimal points from examples for numeric fields that are integers

• Clarified XML response behavior when no data is found and which messages will return an empty QueryResponse as opposed to an empty element of the message type requested.

21.0 1007E0048.21 6/30/06 [ahb] • Updated text in Deliverability Analysis

query and message description based on comments from SPP

• Corrected typos resulting from copy and paste from other sections

• Changed all XML example quotation marks to straight quotes so XML examples are copy and paste friendly for text editors

• Added comments on zero padding of hour and interval values in the common datatypes section.

22.0 1007E0048.22 8/9/06 [ahb] • Replaced erroneous (cut and paste)

reference to "URDIntervalViolation" with "URDInterval" in section 9.25.1

• Replaced references to element name "URDViolation" with "URDIntervalViolated" in the examples within sections 7.30.5, 7.31.4 and 9.25.4 thus making the examples consistent with their respective preceding "Data Description" sections and the XSD file.

• Removed extraneous "resource" and "type" attributes from query example in section 7.30.5 (they were present as attributes and elements). This makes the example consistent with the associated data description section (7.29.2) and the XSD file.

• Replaced erroneous (cut and paste) reference to "LoadForecastHourly" with "LoadForecastInterval" in section 7.29.6

• Added section 4.9.7 discussing ordering of


xxi

Ver #


XML elements and attributes • Reordered elements in XML examples in

sections 7.5.6, 7.6.5, 9.3.2, and 9.3.4 to comply with order defined in XML schema.

• Clarified optionality of EnabledTime and DisabledTime in CurrentEISOfferCap message in section 9.3.3

• Changed order of attributes in DeliverabilityAnalysis element examples in sections 7.9.6, 9.5.2 and 9.5.4 to match what MUI will send. Note that attribute order is functionally irrelevant and this change is merely for readability..

• Corrected value error in example in section 9.3.4.

23.0 1007E0048.23 6/5/08 [ahb] • Updated all references to ResourceType

field to include value “XGEN” in chapter 5, 7 and 9.

• Updated sections 5.4, 7.24 and 9.21 to include modifications to the ResourcePlan message structure and meaning including multiple ramp rates and new limits.

• Updated section 9.25.3 to include new URD waiver reason codes.

• Updated sections 7.14.3 and 9.11.3 to include new settlementLocationType value “EXT” and “XGEN”.

• Added sections 6.1.3 and 6.1.4 discussing multiple notification listeners and retry behavior.

• 24.0 1007E0048.24 6/23/08 [ahb]

• Updated resource plan status descriptions in section 9.21.1 to match market protocol document text

• Removed “valid” field from section 9.21.3 as it is no longer in the XML schema

25.0 1007E0048.25 6/27/08 [ahb] • Added terminology definitions for “Control


xxii

Ver #


Area” and “Balancing Authority” in section 1.4

• Fixed various typographcical and grammatical errors throughout document

• Added missing text for ReturningURDLovkecResource to section 2.3

• Updated availability description for ShortTermLoadForecast in section 2.4

• Added additional description text for EISOffer in section 5.3

• Clarified description of DeliverabilityAnalysis message in section 6

• Changed minMW/maxMW to minEconomicMW/maxEconomicMW in sections 7.22.6, 7.26.1, 7.25.1, 9.18, 9.21.1, 9.22 and 9.23

• Removed XGEN from resource type list for non-applicable messages in sections 7.25.3, 7.26.3, 9.22.3 and 9.23.3

• Changed “hour” attribute to “interval” in data example in section 7.29.5

• Added ConstraintType enumeration value “ImportCap” to DeliverabilityAnalysis data description in section 9.5.3

• Added field PlanManualMW to OverUnderCommitment message in sections 7.22 and 9.18

• Clarified Resource Plan message description in section 9.21.1

26.0 1007E0048.26 6/30/08 [ahb] • Grammatical and typographic corrections

from final review • Added additional data validations to section

9.21.1 • Changed ResourceType field type from

ResourceType to InternalResourceType in sections 7.25.3, 7.27.3, 9.22.3 and 9.23.3 to support restriction of “XGEN” value

• Changed EmergencyRampRate field type


xxiii

Ver #


from MWRateType to MWNonZeroRateType in section 9.21.3 to support restriction of 0 value

27.0 1007E0048.27 7/7/08 [ahb] • Updated Market protocol document URL in

section 2.5 28.0 1007E0048.28 8/12/08 [ahb]

• Corrected missing and transposed field descriptions in section 9.21.3

29 1007E0048.29 10/30/08 [ahb] • Corrected typo in section 9.21.1 to state the

emergency ramp rate must be greater than or eqal to the up and down ramp rates.

• Corrected typo in section 7.21.2 commitment was spelled with 4 “m”s.

30 1007E0048.30 7/28/10 [ahb] • Added the following new values to the

ResourceStatusType enumerated type: − QuickStart − Intermittent − Startup − Shutdown − Testing − QualifiedCogeneration − ExigentConditions

• Created new message type ViolationRelaxationLimit and corresponding query type QueryViolationRelaxationLimit

31 1007E0048.31 9/1/10 [amj] • Removed the following new values from the

ResourceStatusType enumerated type: − Intermittent − Startup − Shutdown − Testing − QualifiedCogeneration − ExigentConditions

Note that version .30 was never moved to PROD. SPP intends to add those back in Phase 3 of the 2010-2 project. In addition,


xxiv

Ver #


removed references to Manual being removed in next revision.

32 1007E0048.32 11/10/10 [amj] • Added the following new values to the

ResourceStatusType enumerated type: − Intermittent − Startup − Shutdown − Testing − QualifyingFacility − ExigentConditions

33 1007E0048.33 3/2/11 [ahb]

• Removed “Manual” status from the ResourceStatusType enumerated type and removed text referencing that status.

34 1007E0048.34

5/6/11 [rrb] • Changed the <Constraint> to <ConstraintType> in ViolationRelaxationLimitQuery section 7.32.1 • Completed the Query Data Description table in section 7.32.2 • Added a new Request,Response messages for CalculatedCurtailmentLevel to support PRR211

35 1007E0048.35

5/17/11 • According to section 3.1.6.2 of 1007E1135.3 - EIS Market Release 1.0 DDN.doc, query for URD Interval was modified to remove “ManualResourcePlan” and add “Non-Dispatchable Resource”.

36 1007E0048.36

6/28/11 • Query for CalculatedCurtailmentLevel defined in version 34 was not supporting for QueryAll case. Instead of adding extra QueryAllCalculatedCurtailmentLevel a new type was added QueryByOptionalResourceDayHourType. The resource and type attributes are optional in the

Formatted: Indent: Left: 0 pt, First line: 0pt, Bulleted + Level: 1 + Aligned at: 0 pt +Tab after: 18 pt + Indent at: 18 pt, Don'tadjust space between Latin and Asian text


xxv

Ver #


new Query type. Section 7.4 was modified to reflect the optionality of attributes. • Moved Query CalculatedCurtailmentLevel, from section 9.30 to 9.3 to keep the alphabetical ordering


1

1. Introduction 1.1 Purpose

The purpose of this document is to describe the participant’s XML-based external interface to the SPP Market Operations System (MOS).

The Market Participant uses this document to guide in the formulation of messages to be sent to the market system and the interpretation of messages received from the system. This document describes the addressing, exchange protocol, data, and XML formulation for all defined messages.

Beginning with version 10 of this document the term “Market Participant” (MP) has replaced the term “Transmission Customer” (TC). For cases where code or form modifications would need to be implemented, the term “TC” remains. An example of “TC” remaining in the specification includes the content of the A/S Capacity Plan field CounterPartyType.

The reader of this document is assumed to be a software engineer whose intent is to understand the requirements of the participant’s interface to the system and to implement the software necessary to exchange data. MP’s authorization or roles are defined by the Local Security Agent (LSA). Data exchange functions include:

• Authorized MP’s query the market database for public data such as load forecast, public operator notices, published market clearing prices, and so forth.

• Authorized MP’s submit resource plans and ancillary service capacity plans.

• Authorized MP’s submit imbalance energy imbalance service capacity plans.

• Authorized MP’s receive dispatch instructions and other notification messages from the market system.

For the most part, the business market rules that govern the data exchange for the energy market system are not described in this document. Market rules are published by SPP separately and referenced in section 2.5.


2

1.2 Technology Prerequisite Knowledge In order to design and implement the XML data exchange software interface to the system using this external interface, the reader should be familiar with:

• Using XML for data description, XML Schemas, XML Namespaces, and XML parsing and validation.

• Soap and Web Services Technology.

• Protocols HTTP, HTTPS, and TCP/IP.

• Security and authentication technologies: encryption, authorization, and SSL (secure sockets layer), and PKI.

• General network communication software methodology.

1.3 Document References The following references are suggested for the technology used by the programmatic API. Note: There are many different references describing XML, SOAP, and Web Services. Those listed below are merely typical and do not represent any kind of endorsement or recommendation.

[T1] Professional XML, 2000 by a myriad of authors, published by Wrox Press. There is also a Beginning XML by the same publisher but this edition here is more complete.

[T2] Professional XML Schemas, 2001 by a countable set of authors, published by Wrox Press. This book also has sufficient discussion of XML namespaces to provide background for the Programmatic API.

[T3] Designing Web Services with the J2EE 1.3 Platform, 2004, published by Sun Microsystems. This reference has a modern and up-to-date description of web services and SOAP from the perspective of the Java language and technology. For other perspectives such as using Microsoft .NET, other books can be consulted.

[T4] SSL and TLS, Designing and Building Secure Systems, 2001 by Eric Rescorla, published by Addison-Wesley. A good overview of the SSL protocol. However, it is recommended that SSL capability by acquired from a 3rd party vendor or the OpenSSL software be considered.

[T5] RFC 2616: Hypertext Transfer Protocol, HTTP 1.1, 1999 by R. Fielding et’ el, published by the Networks Working Group, IETF.


3

The best description of HTTP is the RFC documenting the standard.

1.4 Terminology The following terms and acronyms are used by this document.

ACK – acronym meaning acknowledgement and indicates a normal and successful acknowledgement message. Contrast with NAK.

AS – acronym meaning Ancillary Service, used in the XML schema.

Asynchronous Messaging – see push messaging.

Balancing Authority (BA) - the responsible entity that integrates Resource plans ahead of time, maintains Load-interchange-Resource balance within a Balancing Authority Area, and supports Interconnection frequency in real-time

Balancing Authority Area – the geographic area for which a Balancing Authority is responsible. This term is interchangable with Control Area.

Control Area (CA) – a geographic area within which load, interchange and generation are balanced.

CRLF – acronym meaning Carriage Return Line Feed and is the definition of a line terminator. A line is contiguous set of octets (8-bit characters) that is terminated by a CRLF character. The CRLF character is often platform dependent and may be defined as the hex codes 0x0D, 0x0A or simply as the hex code 0x0A. The usage of 0x0D, 0x0A two-character couplet is standard for Windows platforms (e.g. Windows NT). The usage of 0x0A, single-character, is standard for many Unix platforms. The CRLF can be created using language features for generating a new-line character such as the C escape character \n.

Character Data – is the XML term that defines the non-markup data that exists between an XML start and end tag. For example, given a start and end tag of UNITMW, the character data in the following example is the number 400: <UNITMW>400</UNITMW>.

Digital Certificate – is an electronic object that acts as an identity card that establishes your credentials for doing business or other transactions over the Internet. A digital certificate is issued by a certification authority and it contains your name, the name of your organization, serial number, and expiration date. A digital certificate has a copy of your public key (generated when the certificate is assigned) which is used to translate and understand a


4

channel of communication which is encrypted using your private key. The current digital certificate standard called X.509 is used and supported by the SPP energy market.

DTD – acronym meaning Document Type Definition and it is defined by the XML specification as the statements that describe the elements, attributes, and entities that comprise an XML document. This specification uses the XML Schema only (see entry for XML Schema). DTDs are not used.

HTTP – acronym meaning Hyper-text Transfer Protocol. HTTP is an application-level protocol for distributed, collaborative, hypermedia, information systems. Or, more simply, HTTP is a network communications protocol used to send and receive data over the Internet. The version of HTTP used by this specification is 1.1 and this is often referred to as HTTP/1.1. The HTTP/1.1 protocol is defined by RFC 2616.

HTTPS – acronym meaning Hyper-text Transfer Protocol Secure. HTTPS is a secure protocol where the security is established by SSL (see terminology entry). HTTPS does not define nor does it add new communications features to HTTP, it is merely a secure version of HTTP. The HTTPS name is used to specify the protocol in the URL declaration to identify it as being secured by SSL.

IETF – acronym meaning Internet Engineering Task Force and it is the body whose members work together to define, specify, and regulate the various standards used for Internet network communications. The RFCs referenced by this specification are defined and maintained by the IETF. The IETF web site can be consulted for more information: www.ietf.org.

ISO – acronym meaning International Standards Organization and it is the standards body responsible for a number of international standards used implicitly and explicitly by this document. Explicit standards cited by this specification include ISO 8601 used to define Date and Time standards and conventions; and, ISO-8859-1 used to define the XML operative character set. In the deregulated electricity industry, ISO also means Independent System Operator. That definition is not used in this document.

LIP – acronym meaning Locational Imbalance Price, which is synonymous with Locational Marginal Price (LMP), defined below.

LMP – acronym meaning Locational Marginal Price, which expresses the cost of delivering the next MW (or other increment) of power to a particular location, or the savings from reducing load by 1 MW (or other increment) at that location. LMPs are calculated

http://www.ietf.org/�


5

for each pricing node (pnode). LMP is synonymous with LIP (Locational Imbalance Price).

MP – Market Participant is a participant who has registered resources. Common authorization includes the ability to submit resource plans, ancillary service capacity plans, and energy imbalance service offers into the SPP market system.

Market User Interface (MUI) – the software suite that serves the market web pages, provides the XML upload facility, and houses the SOAP web services for the external XML interface.

NAK – is the acronym meaning negative acknowledgement and is the opposite in meaning to the ACK acronym. NAK is commonly given when a network communications message is rejected or not processed completely. Contrast with ACK.

Operating Hour – An hourly market interval. The “next” operating hour would be whatever hour of the day follows the current hour.

Private Data – refers to access control of data. Private data is data that is private to a given MP. Private data includes resource plans, ancillary service capacity plans, energy imbalance service offers, and dispatch instructions. Access permission must be granted to read and write private data. Such access permission is implicit to the MP who owns the data.

Public Data – refers to access control of data. Public data is data that is common to all registered participants (both the generic market participant and the MP) and possibly the general public. Contrast public data with private data.

Push Messaging – push messaging is an asynchronous sending of messages to participant message listeners by SPP. This is referred to as asynchronous because it is not a response to a requested message (e.g. Request/Reply). Thus, it is activity asynchronous to the activity of the participant. Therefore, the participant must always be listening for asynchronous messages. This type of messaging has become more popularly known as push style messaging because the message is pushed by SPP to the participant as opposed to the more normal request message issued by the participant. Pushed messages are also called notifications and deployments.

RFC – acronym meaning Request For Comments. The RFC is the documentation method used by the IETF for developing and documenting network communications standards for the Internet community. Several network communications standards cited by this specification are defined by RFCs. Each RFC is identified by a


6

number. For a complete list of RFCs and to obtain copies of RFCs, see the information located at the IETF web site: www.ietf.org.

Request/Reply – is a messaging style where a client sends a request message to a server and the server responds with a reply message. Request/Reply is also sometimes called Client-Server messaging. In the case of the external interface, the participant is always the client who initiates the request and the RTO market server is always the server who responds with a reply.

SOAP – means Simple Object Access Protocol and it is the protocol used to wrap the various market data content messages described by this document. SOAP is used in a number of different messaging patterns. Various profiles of usage have been established and documented. The profile assumed by this specification is to use SOAP as a message wrapper for the message profile defined by Web Services.

SD – acronym that designates a resource that is flagged as a “SelfScheduled” resource in the Resource Plan. Self-Dispatch and SelfScheduled are synonymous.

SSL – acronym meaning Secure Sockets Layer. SSL is a protocol standard used to establish a secure, encrypted, connection between a given client and server. SSL Version 3.0 is the protocol used for establishing the secure communications between participants and the RTO market server. SSL is an industry de-facto standard developed originally by the Netscape Corporation.

TCP/IP – acronym meaning Transport Control Protocol over Internet Protocol. TCP/IP is actually two separate protocol standards however, as used in this specification (and, in most other applications), TCP/IP are considered a single network communications protocol. TCP/IP is the protocol specified by various RFC documents published by IETF (RFCs in this case are not as useful as other more popular publications of the TCP/IP standard). TCP/IP is used as the carrier protocol for all messages defined by this specification.

URI – acronym meaning Uniform Resource Identifier and is a similar construct to URL (defined next). URL in fact is a kind of URI. The URI is used to name Internet resources that are not necessarily Internet locations. More information on URI can be found in RFC 1630.

URL – acronym meaning Uniform Resource Locator. URL (which is also a URI) is the standard method for specifying network addresses and network resources used by Internet protocols. The URL defines the protocol, network host address, optional port

http://www.ietf.org/�


7

number, resource path and fragments. URLs are used to specify the RTO’s server addresses that receive messages sent by the participants. URL is defined by RFC 1738.

Valid – as used in this context, valid is the measurement of an XML document that is correctly formatted according to its schema. The RTO accepts only valid XML documents in messages received from participants. All valid XML documents are implicitly also well-formed.

W3C – is the acronym meaning World Wide Web consortium which is a Internet community standards body whose purpose is to develop, publish, and maintain standards for the Internet community. Since W3C is not a government body, its publications are called recommendations as the term standard is defined as government authorized. The XML and HTML recommendations (aka standard) is published by the W3C. More information on the W3C publications and organization can be found at their web site: www.w3c.org.

Web Services – Web Services provide a standard means of interoperating between different software applications running on a variety of platforms and/or software frameworks (e.g. Java J2EE, Microsoft .NET). Using Web Services features and tools, client interface programs can be automatically generated to manage the network connection and the transfer of XML messages. Tools are typically designed to read the WSDL (see WSDL entry) and generate software components per the architecture of a given framework. For example, tools supplied by .NET would be used to generate .NET compatible software. Or, tools supporting Java would generate Java compatible software.

Well-formed – is used to measure an XML document that is formatted according to the syntax rules set forth by the XML recommendation. A well-formed document can be correctly parsed by an XML parser. A document that is not well-formed may fail to parse completely.

WSDL – Web Services Definition Language is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. This MOS usage of web services employs documented-oriented (sometimes called document literal) information only. The WSDL is specified as an XML formatted file that is typically made available as a public accessible file on the web server hosting a web services application. The WSDL file is published on the SPP MOS web servers.

http://www.w3c.org/�


8

XML – is the acronym meaning Extensible Markup Language. XML is a W3C published recommendation. XML is used as the basic format method for all messages defined by this specification. More information on XML can be found at the web site: www.w3c.org/xml.

XML Namespaces – provide a mechanism for qualifying the name of an XML coded entity per a unique identifier defined by a URI. The use of namespaces allows element and other tag names to be derived from more than one vocabulary without conflict or collision. Namespaces, though optional with many XML usage patterns, are required for this specification. For more information, consult the web site www.w3c.org.

XML Schema – provides an improved means of declaring structure and content of an XML document. XML Schema is a replacement for the older document type definition specified by the DTD. Use of XML Schemas are required by this specification. For more information, consult the section on XML Schema at the web site www.w3c.org or references [5] and [6] cited in section 1.3 of this document.

http://www.w3c.org/xml�




9

2. External Interface Data Exchange Overview This chapter provides an overview of the data exchange sets and data descriptions involved in the SPP market operations system.

2.1 Market Participants The participants of the day-ahead capacity analysis and real-time energy imbalance service market that exchange data with the SPP market operations system include:

• MPs that provide resource plans, ancillary service capacity plans, energy imbalance service offers and load forecasts.

• MPs that actively listen and receive notifications and dispatch instructions.

• Participants that view publicly available data such as load forecast, market clearing prices, etc.

2.2 Submitted Data MPs submit data into the market prior to market close1 for the data set. The following data submittals have been defined:

• Resource Plan

• Ancillary Service Capacity Plan

• Energy Imbalance Service Offer

• Participant Load Forecast

2.3 Notification Data MPs may establish a web listener to receive messages sent out by SPP to registered participants. Such participants must have registered a listening URL with SPP and must have executed a connectivity test to validate their listening software. The following data notification messages have been defined:

• ASCapacityObligation is published by 7:00 AM on the day ahead of the operating day.

• Dispatch instructions are published for each MP who is awarded balancing energy. EIS Dispatch instructions are sent each 5-minute interval during real-time on the operating day. OOME

1 See SPP Market Protocols document (referenced in section 2.5) for up to date timeline and submission deadline information for each submittal type


10

Dispatch instructions are published by market operator demand throughout the real-time operating day as needed.

• MarketSchedule is published when it is changed or updated.

• MismatchASCapacityPlan notification is published on the day ahead of the operating day.

• InvalidResourcePlan notification is published hourly for the next hour, daily for the next day or as a result of an operator executed validation of ResourcePlan data.

• OperatorMessage is published by the market operator as needed.

• OverUnderCommitment is published hourly for the next 1.5 hours, daily for the next day or as a result of an operator executed validation of Resource Plan, Participant Load Forecast and energy schedule data.

• EISOfferCap notifications are sent out once per operating day

• EISOfferCapEnabled / Disabled notifications are sent out at the time of the event to which they refer

• URDInterval notifications are sent out for each RTB interval

• URDResourceLocked / Unlocked notifications are sent out at the time of the event to which they refer

• ReturningURDLockedResource Notifications are sent out each 5-minute interval starting 3 intervals prior to the return of a URD-locked resource.

• SelfDispatchMin/MaxViolation messages are sent out when a self dispatched resource fails energy schedule validation

• DeliverabilityAnalysis messages are sent daily for the next day or as a result of an operator executed deliverability calculation.

• Ping, used for link and web listener periodic integrity tests, is sent by market operator request or periodically according to a market operator entered schedule.

Note: See SPP Market Protocols document (referenced in section 2.5) for up to date timeline information

2.4 Query Data MPs may query for private data (e.g., data submitted or market results), notification data (i.e., data issued as notifications), or


11

public data (e.g., market clearing prices). In addition to the submitted data and the notification data already mentioned above, other query data includes:

• Energy LMP data is available on an hourly basis during the real-time operating day.

• Midterm Load Forecast is updated daily and made available by 7:00 AM on the day ahead of the operating day.

• Shortterm Load Forecast is updated every 5 minutes for 5-minute energy balancing intervals up through one hour ahead of real-time during the operating day.


2.5 Day-ahead and Real-time Operation Timeline The SPP market operations timeline is specified in section 2 of the Market Protocols document. The URL of that document follows.

http://www.spp.org/publications/mkt_protocols_7.0b.doc


12

3. Introduction to the Programmatic API The programmatic API is an XML based messaging protocol used for the exchange of messages between market participants and SPP. The XML message is an SOAP wrapped payload carried by the HTTP protocol per the standards and recommendations specified for Web Services data exchange2.

The participant software must implement the messaging protocol according to the specification described in this document. This software implementation relies heavily on standard technologies that can be obtained freely on the Internet (i.e. open software) or that can be obtained from 3rd party vendors.

3.1 Messaging Overview The programmatic API is a messaging API used by SPP to exchange data with market participants. In function, the programmatic API mimics the interactive web user interface. Almost all functions supported by the web pages are also supported by the programmatic API.

3.1.1 Participant Roles This specification assumes two parties identified as the client party and the server party. For most of this discussion, these two parties will simply be referred to as the client and the server.

For the majority of the messages defined by this specification, SPP is the server party and the participant (MP or other) is the client party. For notification type messages though, these roles are reversed and SPP is the client whereas the participant (MP in this case) is the server.

3.2 Request/Reply Messaging This messaging protocol is called request/reply (or, request/response). The client issues a request to the SPP server and a reply (response) is returned by the server to the client. The client initiates all request/reply messages.

The following diagram illustrates the request/reply protocol.

2 Web Services are defined by the W3C standards (actually referred to as recommendations). These Web Services recommendations and specifications can be found at the W3c web site www.w3c.org/2002.ws.


13

The client is the market participant that is sending a request to SPP’s server handling the message. The processing steps are outlined below:

Step 1 – the client software formulates the request message and sends it to the server. Request messages may be to submit data (e.g. offers and plans) or query the market database. After sending the request, the client software waits for the response (step 4). Because the client software initiates the request and waits for the response, this is considered a synchronous messaging protocol.

Step 2 – the server software is actively listening for new messages and receives the message sent by the client. The server software processes the message, which includes validating the message request, processing message action, and formulating the message response (step 3).

Step 3 – the server formulates the response as either an ACK (successful request) or a NAK (unsuccessful request resulting in error response). The successful request may be a simple indicator of the success of the requested action or it may also include a data packet returned to the client as the response to the requested action (e.g. a data query). The unsuccessful response will always include an error packet that identifies each of the errors encountered in the request.

Step 4 – the client software receives the response message and acts accordingly depending on whether the response indicates success (ACK) or failure (NAK).

SPP’s server implements a message listener using a standard HTTP web server that supports SSL for encryption and


14

authentication3. Therefore, submitting a message request is tantamount to submitting an Internet web page request; although, instead of using the HTTP GET command, the HTTP POST command is used.

Therefore, the participant client must implement software that makes an HTTP connection using SSL along with the authentication scheme (digital certificate). Once the HTTP connection is established the message is sent as a POST command to the server.

3.3 Push (Asynchronous) Messaging This messaging protocol is called push or asynchronous messaging. With push style messaging, the client is the SPP server computer that issues requests to the MP that acts as the server. The participant must be actively listening for these request messages pushed out by the SPP computer. Because the participant must be actively listening for these messages and because the participant does not request messages from the RTO, this messaging is also called asynchronous because the messaging is asynchronous to the participant's activity.

The following diagram illustrates the push messaging protocol.

The client is the SPP computer that is sending a request to participant's web listener server handling the message. Note that this is the reverse of the typical request/reply where the participant

3 All message exchanges between the participant and the SPP server uses HTTPS protocol which is HTTP over an SSL (encrypted) session. The name HTTP names the protocol commands, the suffix of S refers to the secure connection. When discussing the protocol, the name HTTP will be used.


15

is the client and the RTO is the server. The processing steps are outlined below:

Step 1 – the RTO software formulates the request message and sends it to the participant's web listening server. The messages are all called notifications since they are used to notify the participant of data, events, or operator messages.

Step 2 – the participant's web listener software receives the request message and validates that it has received it correctly.

Step 3 – the participant computer issues a NotificationSuccess message (defined later) as the response to indicate that the message was received correctly. If the a connection was successfully established to the listener but the message was received with errors (XML parsing or validation errors) then the NotificationFailure message is sent back to the RTO as the response.

Step 4 – the RTO receives the response message from the participant and logs the success or failure of the operation. If the message was not received correctly or if the message push timed out without successful response then the operator is notified and a manual operator initiated transaction begins4. Notification messages are not automatically resent when the participant's web server fails to respond.

The participant computer is responsible for acting on deployment messages by executing the dispatch instruction in a timely manner. However, the execution of the dispatch is not part of the messaging protocol. Thus, the response message sent back to the RTO does not indicate that the message was executed, merely that it was received.

The participant is responsible for establishing a web listening server that listens on the URL designated to SPP. One URL shall be specified as the participant's listening address. If the participant computer system consists of multiple server computers then a virtual address or some other method of handling the HTTP content switching should be implemented. Thus, all redundancy and failover schemes implemented by the participant are transparent to the RTO.

4 The operator intervenes in this situation because the data is often time-sensitive such that relying on automatic retry can result in sufficient delay where the data itself is obsolete by being out of date.


16

3.4 XML File Upload and Download The browser based web interface supports a XML file upload/download service via a web page. This service is available to any registered participant and it can be used to substitute for the need of developing a software programmatic interface.

Using the file upload and download service, the participant may:

• Format any valid QueryRequest message (including QueryByTransaction) as a file for submittal to SPP.

• Format any valid SubmitRequest message as a file for submittal to SPP.

When a file is submitted, it is uploaded to SPP. The response file is made available as a file download to the participant's computer. The participant may choose to open this file immediately using the application assigned by the MIME type or the participant may save the file on their local computer.

The participant should configure his web browser to handle the file MIME type in the way desired. The file type is .xml and the MIME configuration for many browsers (such as Microsoft Internet Explorer) is to display the XML file in a formatted web page. Although the web browser user can display and view the page and then save the page as a file, this is not the best method for handling these downloads. The reason is that the browser may change the formatting of the data prior to saving the page content. For example, in some cases, special characters may be changed or blank space characters may be compressed that are meaningful as data.

Therefore, to handle the download more correctly and efficiently the web browser should be configured to ignore the xml MIME type which will then cause the Internet Explorer to offer up the download file chooser dialog to specify a location and filename for saving the file directly to the user's computer.

The required format for file upload and download requests is documented in Chapter 4 of this specification.

3.5 Web Technologies As evident by the previous discussion, the programmatic API is implemented using standard web technologies. In particular, the following technologies are used by this scheme:

• XML, Extensible Markup Language


17

• SOAP, a web services API

• HTTP/HTTPS

• SSL and Authentication

• Web Services

3.5.1 XML – Extensible Markup Language XML means eXtensible Markup Language. It is a structured, hierarchical, tag based coding language that is suitable for describing data that is sent over the public Internet. There are many good references for learning about XML and a few are listed in section 1.3 ([T1], [T2]) of this document. The specification and details of XML will not be repeated here. However, a few comments on “why” and “how” XML is used is discussed briefly below.

XML Versus CSV

XML is a replacement for data file exchange using CSV format. CSV means comma separated values and refers to a commonly used ASCII coded file format where each line is a set of data values separated by a comma (or, some other value separator character such as a tab). Each line typically refers to a set of associated data and given a particular interpretation by the producers and consumers of the data. The interpretation is usually ruled and defined by an external element that is often cryptic and obscure.

XML has the following advantages over CSV:

• XML is usually easily readable where each data value is described by a name. CSV often does not describe data by name.

• XML supports structure allowing nested or hierarchical relationships that can be validated for correctness. CSV is necessarily flat in structure often leading to the need for repeating groups of data to model data hierarchy.

• XML supports strong data typing (using XMLSchema language) that can be validated as part of the XML parsing process. Since parsers are standard, given the XMLSchema, an XML message can be parsed and validated easily by anyone. Custom validation software is not required (for example, standard tools


18

such as XMLSpy5 can be used to validate a message against the schema).

• XML supports data transparency where character data can be composed of any character code (assuming a few proper escapes where needed by the language). CSV on the other hand has trouble with embedded commas in character data if the comma is a value separator.

XML Schema

XML Schema is a relatively recent addition to the XML family of standards. XML Schema is a structured language used to describe other XML documents. XML Schema is itself an XML document described by an XML Schema.

XML Schemas are a replacement for the XML DTD (document type definition) which is still commonly used to describe XML. A DTD though lacks many of the features of XML Schema, such as strong data typing, name space management (DTDs do not support name spaces). XML Schema also supports a more powerful relationship and structure specification.

XML Schema is used to describe all market data exchange messages. DTDs are not used and they are not supported. There are many references describing XML Schema and how it is used. Those references already listed for XML ([T1], [T2]).

XML Namespaces

XML Namespaces are used to support the association of specific XML markup to a particular vocabulary and schema. Namespaces allow the mixture of XML markup from different vocabularies. In fact, using SOAP and XML Schemas require the use of namespaces and at least two vocabularies.

An XML Namespace is a unique identifier specified using a URI (uniform resource identifier). Thus, a namespace identifier looks like a URL or a web page address. However, an XML Namespace identifier is not a web page address and there is no expectation of finding any resource at the URI that is used. The combination of the unique domain name and the URI path establish the uniqueness that is required of namespace identifiers.

The use of XML Namespaces as shown later in this document is required. Failure to use the proper namespace will result in an

5 XMLSpy is a third-party utility product used to create and validate XML schema and XML instance documents. XMLSpy is recommended as a tool for anyone using XML and is available from ALTOVA (see www.xmlspy.com or www.altova.com).


19

XML validation failure and an error response. More information on XML Namespaces can be found in the XML references already cited.

3.5.2 SOAP – A Web Services API SOAP means Simple Object Access Protocol. It is based on XML and is designed for the exchange of information in a distributed computing environment. The SOAP protocol was originally designed for RPC (remote procedure call) style of computing but it also supports other message exchange profiles. SOAP is not used as an RPC by SPP's energy market system; rather, it is used to wrap message payload in a common, standard, way to facilitate handling, routing, and common processing.

The SOAP protocol is an outside wrapper called the Envelope. This Envelope encloses all other XML data. The Envelope itself contains two distinct structures: Header and Body. The Header element is not used by this specification (it is considered optional by SOAP). The Body element contains the entire payload.

In addition to the SOAP XML elements, the SOAP protocol uses custom HTTP request headers to help communicate the intent of the message. HTTP request headers are not the same as SOAP headers, which are not used in MOS. An HTTP request header is a piece of metadata for the HTTP protocol, and does not appear in the request body content as the XML message does. In SOAP 1.1 a “SOAPAction” header is used to specify the desired action to invoke on the web service. See section 4.3.1 for more information on “SOAPAction” and other HTTP request headers.

The SOAP standard used by this specification is SOAP 1.1, but backward compatibility to 1.0 is also provided.

There are a growing number of good references for SOAP; the one provided here (reference [T2]) is just one recommendation.

3.5.3 HTTP/HTTPS HTTP means Hyper-text Transport Protocol and HTTPS means Hyper-text Transport Protocol Secure. HTTP is the transport protocol used by the programmatic API (this specification) to carry the XML messages over the Internet. HTTPS is the same protocol as HTTP except that it is a secure, encrypted session established by SSL. All the commands, headers, error responses, and body format for HTTPS is the same as HTTP. Therefore, in this and many documents, HTTP is generally used to refer to both HTTP and HTTPS with regard to the actual protocol rules. The HTTP


20

standard is specified by RFC 2616 (reference [T5]). HTTP 1.1 is used by this specification.

Although HTTP is the protocol for message exchange using the programmatic API, it is not the only method supported. File transfer is also supported for upload and download. The File transfer format and naming rules is described later in this document.

3.5.4 SSL and Authentication SSL means Secure Socket Layer and it is a protocol used to establish a secure, encrypted, TCP/IP session between the client and server computers. SSL is used for all data exchange using this programmatic API. SSL is not the authentication method though -- it merely provides the security encryption for the authentication means.

SSL is an industry defacto standard developed by Netscape Corporation and it is the most commonly used and supported encryption protocol. Other protocols exist. The standard TLS is an IETF endorsed standard to replace SSL and thus is compatible with SSL. TLS means Transport Layer Security. SSL is referenced instead of TLS because it is still the industry dominant protocol used for establishing an encryption channel between client and server.

Authentication is the establishment and verification of the user submitting the requests to the RTO server. Authentication is based on X.509 digital certificates. All messages submitted to RTO server must include the appropriate authentication credentials.

3.5.5 Digital Certificates The MOS uses digital certificates for authenticating all inbound connection attempts (MUI) and providing credentials for all outbound connection attempts (Notifications). Numerous standards for certificate format exist, but the standard used by MOS is X.509. For detailed information on the X.509 standard see www.ietf.org/html.charters/pkix-charter.html.

The following components and terms are important to understand for using certificates with MOS

• Certificate Authority (CA) – A trusted organization that signs and issues digital certificates for clients and servers. One of the steps an authenticating server will perform in determining a digital certificate’s validity is to verify that the certificate is signed by a CA, and that the CA root certificate exists in the server’s trust store. If the CA used is not a common CA, then the

http://www.ietf.org/html.charters/pkix-charter.html�


21

customer must send the certificate chain that authenticates the CA to SPP so that it can be added to SPP’s trust store.

• CA Root Certificate - A digital certificate representing the credentials of a CA. Often a CA certificate will be signed by another CA, creating what is known as a “certificate chain”. A CA certificate that is not signed by another CA is known as a “self-signed certificate”. In order for a server to accept client certificates signed by a certain CA, the CA root certificate (or a CA certificate from higher CA in a certificate chain) must be imported into the server’s trust store.

• Trust Store – A file maintained by both clients and servers that contains CA root certificates. When a certificate is going to be sent by a client or processed by a server one of the first actions is to verify that the root certificate for the CA who signed the certificate exists in the trust store.

• Client Certificate – A certificate presented by the client when attempting to access a secure server. The certificate contains unique information about the client, as well as information about the CA that signed it. A client certificate is considered valid if it is current (hasn’t expired), signed by a CA that the server trusts and does not appear on the CA’s CRL.

• Certificate Revocation List – A file maintained by a CA that contains a list of all certificates issued by the CA that have been revoked before their expiration time. The CA makes this file available to its customers. A secure server must always have the latest CRL in order to prevent revoked certificate holders from accessing the system.

• Server Certificate – A certificate presented by the web server to a client attempting to establish a secure connection. A server certificate is considered valid if it is current (hasn’t expired), signed by a CA that the client trusts and does not appear on the CA’s CRL. If any of these verifications fail, the client is issued a warning that they are connecting to a potentially non-secure server, which they may ignore if they wish. The public key size of certificates for use in MOS must not be larger than 2048K.


22

4. Common Principles This chapter describes common requirements and messaging concepts used by all message types.

4.1 Participant Registration All market participants (both generic participants and MPs) using the XML programmatic interface must be registered with SPP. Each registered user must have appropriate authentication credentials that establish:

• A user name.

• A participant identifier or company name defined at the time of registration.

• Access permission based on the roles defined by the registration system.

The client offering a digital certificate as the authentication credentials determines the user name, participant identifier, and access roles. This X.509 digital certificate uniquely identifies a registered user with SPP. These credentials allow the user to access public and private data according to the participant registration and authentication artifacts.

4.2 SPP Server Addressing All functions and data provided by the SPP Market Operations Server are addressed using a Uniform Resource Locator (URL).

Note: the host computer name, shown below and shown in each subsequent section defining messages, such as portal.spp.org may be changed or there may be more than a single host computer available (such as sand box testing, market trials, training, etc.). The actual host name that must be used will be published by SPP.

The URL addresses are composed of two parts, which are called the left-side protocol and host part, and the right-side URL path part. Thus, the URL shown below: https://portal.spp.org/emkt/services/query

This message has a left side that consists of the string https://portal.spp.org and a right-side that consists of the URL path /emkt/services/query.

The left side is fixed for all queries and submits messages defined in this document. The actual host computer name depends on


23

which system you are using but once a system is chosen (e.g., sandbox, training, market), it is fixed for all message types.

The right side is independent of the host computer choice and dependent on the application system and the message. The following table shows the syntax of the different URL paths supported by this specification.

Function URL Query Public and Private Market Data

/emkt/services/query

Submit Data to Market Operations System

/emkt/services/submit

Query By Transaction (for previously submitted data)

/emkt/services/queryByTransaction

4.3 HTTP Command and Headers All messages submitted to the SPP Server and all messages returned to the participant as responses are coded as HTTP POST command messages.

4.3.1 HTTP Request Message Format The following examples highlight the required format and content of request messages for MUI query, MUI submit MUI transaction query and Notifications

The following example shows the HTTP message format for an inbound MUI data query: POST /emkt/services/query HTTP/1.1 Host: portal.spp.org Content-Type: text/xml Content-Length: ddd SOAPAction: "query" <body content>

The following example shows the HTTP message format for an inbound MUI data submit: POST /emkt/services/submit HTTP/1.1 Host: portal.spp.org


24

Content-Type: text/xml Content-Length: ddd SOAPAction: "submit" <body content>

The following example shows the HTTP message format for an inbound MUI transaction query: POST /emkt/services/queryByTransaction HTTP/1.1 Host: portal.spp.org Content-Type: text/xml Content-Length: ddd SOAPAction: "queryByTransaction" <body content>

The following example shows the HTTP message format for an outbound Notification message POST <TC listener context path> HTTP/1.1 Host: <TC listener host> Content-Type: text/xml Content-Length: ddd SOAPAction: "portal.spp.org/SPP/XMLNotifications" <body content>

Each line of the HTTP headers is described below: POST <context path> HTTP/1.1

Specifies the HTTP command as a POST command. All HTTP messages submitted to the RTO server are POST commands; no other HTTP command is supported. The above line follows the syntax rules of the HTTP Version 1.1 RFC. Usage of HTTP version 1.1 is required. <context path> is the part of the target URL that appears after the host name. Host: <host>

The above HTTP request header naming the host computer is required by HTTP Version 1.1. This names the host computer, which is the same as the host computer specified on the URL. <host> is the part of the target URL between the protocol and the context path. Most likely this is the same computer that your HTTP software connects to though in general this is not a requirement for HTTP (that is, web listeners may establish virtual hosts that can handle HTTP connections of different names on one physical computer). Content-Type: text/xml

The above HTTP request header specifies the MIME type of the <body content>. The only MIME type accepted by the SPP server is text/xml. Content-Length: ddd


25

The above HTTP request header specifies the length, in bytes, of the <body content>. SOAPAction: "<action>"

The above HTTP request header is required for SOAP Version 1.1 messages by the SOAP standard. The header is required but the interpretation of the value and the purpose of the header is dependent on the application itself and not on the SOAP 1.1 standard. For inbound communications to the MUI only three actions are supported: “query”, “submit” and “queryByTransaction”. Notifications will always be sent out from MOS with SOAPAction: “portal.spp.org/SPP/XMLNotifications”

<body content>

This is not an HTTP request header but rather the body content of the message. The <body content> of all messages defined by this specification must be valid XML, and must begin with the following line: <?xml version="1.0" encoding="UTF-8"?>

For more information on the syntax and structure of HTTP requests see the HTTP 1.1 standard specification at http://www.w3.org/Protocols/rfc2616/rfc2616.html

4.3.2 HTTP Response (reply) Message Format The following example highlights the content of a typical response message. HTTP/1.1 200 OK Content-Type: text/xml Content-Length: ddd <body content>

The interpretation of the above lines is standard HTTP as described by the HTTP Version 1.1 RFC. The 200 status code indicates success. All responses returned by the SPP system are considered successful HTTP responses using a 200 status code even if they are reporting an error in the content of the message. If the SPP web server should raise an error or if there is an authorization failure or bad URL then other HTTP error codes can be returned. Codes that may be returned include:

400 – Bad request is returned if there is a formatting error in the headers or the HTTP command line.


26

401 – Unauthorized is returned if the request does not include an authorization header or if the authentication fails to authorize the user.

404 – URI not found is returned if the URL specified on the request is unknown.

405 – Method not allowed is returned if any request to the specified URLs given any other command beside POST. Only the POST method is allowed.

500 – Internal Server Error is returned is some part of the server fails to respond or has crashed. See comment below on SOAP and the 500-error code.

It is possible that other error codes would be received but these are the most common likely to be seen during actual operation.

If a SOAP query results in a 500 code, a SOAP fault message will be returned to the client with text describing the error that occurred. The following example shows the structure of the SOAP fault message <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <env:Body> <env:Fault> <faultcode>env:Server.userException</faultcode> <faultstring>An error occured</faultstring> <detail/> </env:Fault> </env:Body>

</env:Envelope>The interpretation of the 200 success code means that the <body content> can be assumed to be a well-formed and valid XML response that begins with the <?xml version=“1.0” encoding=“UTF-8”?> line and contains SOAP wrapped XML statements per the specification in this document. Any other response code means that the <body content> cannot be assumed to be XML! Therefore, participant software should only attempt to parse and validate XML derived from the body content if and only if the 200 success response code is returned.

4.4 SOAP Envelope In the above HTTP request and response examples, the <body content> refers to the XML SOAP envelope. The SOAP envelope wraps all message content including query requests, query response, submittal request, submittal response, error response, and XML Notifications.


27

The following example shows the canonical SOAP envelope used for all request and response messages. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> --- actual message body goes here --- </env:Body> </env:Envelope>

There are other parts to the SOAP standard that are not shown by this example. For example, encoding style can be specified, other name spaces can be referenced. The SOAP Header, which is optional and may appear before the SOAP Body is not used. It is shown in this example but not in subsequent examples in this document, as it has no application in the MOS. The Header element may be specified as an empty element (as shown above) or it may not be present at all. These other parts to SOAP are not used at this time by this specification.

The actual message content is specified within the <env:Body> element This message must be specified and associated with the correct namespace that is used to validate the message. The following example shows a QueryRequest message enclosed within the SOAP Body: <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> --- actual query request goes here --- </QueryRequest> </env:Body> </env:Envelope>

The namespace is specified as a default namespace on the QueryRequest element. This means that this namespace applies to all other elements from this layer on unless they have other local namespaces associated with them by using a specified prefix.

The SubmitRequest and the QueryResponse and SubmitResponse elements are used with the namespace in a similar fashion.

How one uses namespaces with SOAP and XML in general is not always obvious. The SOAP standard uses namespaces with linked schema in a subtle and sometimes tricky fashion. It is recommended that references such as [T2], [T3] be considered for


28

additional information. How namespaces are used by this specification is described in the next section.

4.5 XML Namespaces Two namespaces are assumed and used by this specification. One namespace is used by SOAP and the energy market XML Schema uses the other namespace as shown below. Note the trailing slash (/) in the SOAP Envelope namespace. These namespaces are:

SOAP http://schemas.xmlsoap.org/soap/envelope/

Energy Market http://emkt.spp.org/2004/emkt/xml

Note that the host computer names on the above namespace URIs are not interpreted in the same way as a host computer name on the URLs discussed earlier in this document. The host computer name specified as part of a namespace URI is fixed. It does not change even if you send your messages to other computers. It is fixed by the software system and changing it requires a change to the SPP server software.

Another namespace that might be specified in some circumstances is the XML Schema Instance namespace. This namespace is typically associated with the xsi prefix and can be used to specify a null value for some numeric values defined in this specification. This namespace has the following URI:

XML Schema Instance (prefix, xsi:)

http://www.w3.org/2001/XMLSchema-instance

Namespaces and how they are used in an XML instance document can be confusing. There are rules that apply to how default namespaces can be overridden by local namespaces.

The examples of namespace usage in this specification are not to be considered fixed and required. There are a variety of methods that namespaces can be used. Given that at least two namespaces are required by all messages in this specification, the following examples show how these namespaces can be specified.

The first example shows the use of default namespaces. <?xml version="1.0" encoding="UTF-8"?> <Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/"> <Header/> <Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryEnergyLMP day="2003-03-02" settlementLocation="LOCATION1" locationType="GEN"> <Hour>5</Hour> </QueryEnergyLMP>

http://emkt.spp.org/2004/emkt/xml�


29

</QueryRequest> </Body> </Envelope>

The namespace usage above defines two default namespaces. The first default namespace is for the SOAP namespace and this is defined on the Envelope element. This default namespace applies to all elements that are not associated with any other local or default namespace.

In the above example, the second default namespace is associated with the QueryRequest element. This second default namespace applies to all elements at this level and deeper (within the query request).

In the next example, a local namespace associated with a prefix "env:" is defined for the SOAP namespace. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryEnergyLMP day="2003-03-02" settlementLocation="LOCATION1" locationType="GEN"> <Hour>5</Hour> </QueryEnergyLMP> </QueryRequest> </env:Body> </env:Envelope>

In the next example, the local namespace prefix of mkt: is specified for the QueryRequest elements: <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mkt="http://emkt.spp.org/2004/emkt/xml"> <mkt:QueryRequest> <mkt:QueryEnergyLMP day="2003-03-02" settlementLocation="LOCATION1" locationType="GEN"> <mkt:Hour>5</mkt:Hour> </mkt:QueryEnergyLMP> </mkt:QueryRequest> </env:Body> </env:Envelope>

There are other variations on this same theme. Namespaces may be defined at any point in the XML instance document. They may be defined as a local namespace with a prefix, they may be defined as a default namespace without a prefix. All of these variations, as long as the rules of XML and SOAP are followed, are acceptable.

For simplicity and clarity, only one variation is used in the examples in this specification. This example uses a local namespace with the env: prefix for the SOAP namespace and a default namespace


30

without a prefix for the SPP market namespace. However, these examples do not necessarily endorse a particular style nor do they suggest that messages received (responses or notifications) necessarily follow this same style6.

4.6 XML Schema Two XML Schema references are required to successfully parse and validate the XML messages described by this document. One schema is for the SOAP 1.1 standard and the other schema is for SPP’s XML messages. They are:

SOAP: http://schemas.xmlsoap.org/soap/envelope/

MOS: http://emkt.spp.org/2004/emkt/xml/

The schema should not be located using the schema Location element inside of an XML message. All schemas used by the SPP server are provided externally. The message content schema, if specified, is never used. You may use the schemaLocation attribute for your own testing or validation but it should not be a part of the submitted messages.

Note: While the namespace given above for SOAP is an actual, live URL where the SOAP schema can be found, the MOS schema is only being distributed externally by SPP at this time. Software written against MOS XML should not try to locate the schema using the URL given above.

4.7 Error Response There are three kinds of response messages returned to the client: success response, success with data response, and error response. The individual message success and success with data responses are described in later sections. The error response is described in this section and is common to all request type messages.

The error response is given for the following types of problems:

• Malformed XML format, that is, unable to parse the XML correctly.

• Invalid XML message, that is, XML content does not validate against the schema. This includes many of the data type, range, relationship errors that can be found.

6 The main reason that we do not stick to a particular style and adhere to it for the system implementation is that this is not always possible. Different software modules that may be used in the system follow their own style of namespace association. The only factor of importance is that all these variations are legal and acceptable.


31

• Violation of business rules includes errors such as market is not open, invalid names or data values, and so on.

When a submit error response is returned, the transaction is cancelled and all changes are rolled back – the market database is not modified. For example, if a data submit message has an error in just one part of the overall message, the entire message and all of its data is rejected. No partial data submits are allowed or supported. If a query request has an error in any part of the request then no data is returned to the client even though other parts may be error free.

Note that if any of the HTTP errors are returned (as described previously) then there is no body returned with the message that is meaningful to this programmatic API (it might be some other body provided by an intermediary component that operates outside of this specification and therefore may be useful). All error responses described in this section are returned in a successful (HTTP/1.1 200 OK) message.

The error response message has the following SOAP wrapped XML format. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <SubmitResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <Error> <Code>ORA-20034</Code> <Text>Market is not open</Text> </Error> … </SubmitResponse> </env:Body> </env:Envelope>

<Error> is used to specify a single error occurrence, there may be multiple Error elements returned in a single error response message.

<Code> is optional and used to specify the error code (if one exists). Error codes may refer to specific software modules used by SPP software. Error codes are only used to communicate a particular vendor's software error event. Error codes may be defined for a range of software (e.g. Oracle, BEA Weblogic, Apache, Tomcat, Linux, Castor, etc.) using numeric codes particular to the vendor. These error codes are not meant to represent a cross-reference index for the <Text> messages. There is not a one-for-one mapping between the codes and an individual text message. These error codes only have meaning to the


32

supplier of the software and should be used in concert with the submission of problem reports or calling the SPP help desk.

<Text> is used to contain the error message text describing the problem. This is a required element and always returned. This text description of the error is the complete description. It does not rely upon additional information that might be part of an error code or other subsystem.

<Line> is an optional line number that can be returned specifying the line where the problem occurred. Not all submittal methods use the notion of a line so this value is not always available and it may not be useful. It depends on the nature of the submitted data.

4.8 Transaction Semantics Each submittal is executed using a transaction and the server logs the submittal request message and identifying aspects of the message. The rules associated with these transactions are supported by XML data submittals only. Although the transaction log also shows activity from the Web browser interface that is supported only to show the historical order of events. The query of submitted data is only available for data submitted via XML.

4.8.1 Transaction Semantics and Transaction Identifier Whenever a submittal request message is processed and is successful, resulting in the modification of the database, a transaction event is created and is uniquely identified by a transaction identifier. This transaction identifier is returned as part of the Success response message.

The data submitted is saved and can be recalled by a subsequent query by transaction. After a period of time, the saved data can be archived and no longer available using the query by transaction request. It may still be available but only by special request to SPP's help desk.

4.8.2 Transaction Log The resulting transaction event log maintains a complete history of all changes initiated by the participant interface, whether initiated by the web user or an XML message submit request. This log is available for review via the web interface. The fields supported include the following:

• Transaction ID

• Participant ID of the owner of the data set


33

• User name of the submitter (or, web user)

• Time and Date of Transaction Event

• Type of Event: Web Submit or XML Submit

• File that contains the message data of the original submit.

• Archive Flag (if set to true, submitted data has been archived offline).

4.9 XML Data Type and Specification Semantics In general, data specified using the XML Schema rules is bound by data type and constraining facets. However, some fields require special care in how they are specified since the user has complete freedom to specify any characters he wishes and some of these cause problems for XML or have dubious interpretations.

4.9.1 Character Case Character case, upper, lower, and camel case must be honored by all XML specified in this document. Within the body of the XML, there are no case insensitive strings. Case must be honored at all times. For example:

• The values of the various enumerated strings, such as URS, DRS, SPIN, or SUPP are upper case only. Other enumerated values may be lower case or mixed case (i.e. Private, Public, Insufficiency, Obligation, Resource).

• The values of resource names are case sensitive. The values of location pricing node (pnode) names are case sensitive.

• All XML attribute names and element names are case sensitive.

4.9.2 XML Boolean Data Boolean data is a recognized type defined by the XML Schema datatypes controlled by W3C. Boolean is binary data represented as true or false. The Boolean values acceptable for true and false are shown in the table below:

State XML Representations True true

1

False false 0


34

For example, if a Boolean element called <Veracity> were specified as input, each of the examples below would represent a true value being submitted: <Veracity>true</Veracity> <Veracity>1</Veracity>

4.9.3 XML Date and Time All date and time values must follow the XML Schema datatype rules for date and time (controlled by W3C). The following date and time formats are used in this specification.

Data Type XML Syntax Date YYYY-MM-DD

Time hh:mm:ss[.SSS]-[zz:ZZ]

Date and Time YYYY-MM-DDThh:mm:ss[.SSS]-[zz:ZZ]

Consult the XML Schema Data Types specification for more examples of the date and time formats.

Fractional Seconds

The [.SSS] portion of the data format shown above represents the fractional seconds portion of the time. Fractional seconds are not used by the SPP MOS applications but fractional seconds may appear in the auto-generated dateTime values as .000 appended to the seconds. Therefore, the client software should be prepared to handle the full definition of the date and time format as specified by the W3C XML Schema Data Types specification.

Timezone

The [zz:ZZ] shown in the syntax examples above refer to the time zone offset that may be specified. This is optional but when employed must be specified per the rules specified in the XML Schema specification. When not specified, the default time zone is the Central Prevailing Time zone. SPP operates the entire market in the Central Prevailing Time zone.

Note that while [zz:ZZ] is the only timezone offset format used in this document and by the MUI, all of the following are valid formats for timezone offsets in the XML schema specification. “Z” The letter Z indicates that the time is

Coordinated Universal Time (UTC), also known as Greenwich Mean Time (GMT) or Zulu time.

-zz:ZZ The minus zz:ZZ format specifies the offset hours and minutes for time


35

zones west of the prime meridian. For example, the offset for Eastern Standard Time, which is 5 hours behind UTC, is –05:00.

+zz:ZZ The plus zz:ZZ format specifies the offset hours and minutes for time zones east of the prime meridian.

All submitted data that is time zone dependent is converted to GMT prior to storage or usage. All displayed data is Central Prevailing Time zone. There is no method for receiving time data for a different time zone. It is recommended that all participants use the Central Prevailing Time zone to help eliminate confusion.

The time zone field is also used to show the duplicate hour during the Daylight Saving Time fall transition day. This is a universally accepted convention to represent the distinction between the first occurrence and the second occurrence of the duplicate hour. More information on this is found in the next section on Daylight Saving Time.

Daylight Saving Time Transition

The market time line honors Daylight Saving Time. In the spring, an hour is skipped so that the day only has 23 identified hours. In the fall, an hour is duplicated so that the day has 25 hours.

During the spring transition, at 2 AM, clocks are adjusted to read 3 AM. Technically, this takes place just before the clock strikes 2 AM. As a result, the hour ending at 2 AM, called 02, never occurs and this hour-ending interval is skipped. The hour-ending intervals of the day during the spring transition day read like: 01, 03, 04, 05, etc.

During the fall transition, at 2 AM, clocks are adjusted back to read 1 AM. Thus, the hour ending at 02 occurs twice and is duplicated. The fall transition day hours read like: 01, 02, 02, 03, 04, etc.

In the fall, since there are two hourly intervals both designated as hour ending 02, there needs to be a method to distinguish between the two. On the XML, there are two different data fields used to specify the hour-ending (depending on the kind of message). One method uses an attribute on an element called hour. The other method uses an element named <Hour>. The methods for distinguishing between the first occurrence of 02 and the second occurrence of 02 during the fall transition is shown in the examples below.


36

Note: The hour and interval endings used by the MUI during the fall daylight savings transition do NOT follow legislation on how the actual calendar progresses. Consider the example below:

Calendar Time MUI Time 0055 CDT 0055 0100 CDT 0100 0105 CDT 0105

… …0155 CDT 0155 0100 CST 0200 0105 CST 0105d7

… … 0155 CST 0155d 0200 CST 0200d 0205 CST 0205

Note that while the calendar will repeat the hour 0100 the MUI will show this time as 0200.

Using the hour attribute

For example, the ASCapacityPlanHourly element for describing the values for a given hourly interval is shown below for the normal (non-duplicate) hour: <ASCapacityPlanHourly hour="2">

If the hour is the duplicate hour in the fall, the isDuplicateHour attribute is included as shown below: <ASCapacityPlanHourly hour="2" isDuplicateHour="true">

This attribute, isDuplicateHour, is defined as optional by the XML Schema with a default value of false. Therefore, if it is not included, it is the same as if you specified a false value. Including this attribute is only necessary on the duplicate hour in the fall, however, there is no harm on specifying it with the false value at other times.

Using the <Hour> element 7 The “d” marker indicates that this time belongs to the second of the repeated hours in the daylight savings transition. This is the same convention used by the MUI to display these hours, and is the equivalent to the isDuplicateHour attribute being “true” for an XML hour or interval.


37

For example, the query for Energy LMP values accepts the <Hour> element to indicate a particular hour to be included in the query. For the normal (non-duplicate) hour, the example is as shown below: <Hour>2</Hour>

For the duplicate hour in the fall, the isDuplicateHour attribute is include is a manner similar to the hour attribute example above: <Hour isDuplicateHour="true">2</Hour>

The handling of the isDuplicateHour is exactly the same whether it is specified in concert with the hour attribute or on the <Hour> element.

Although the most widely used method of representing time is the hour ending value as described above, there are a few situations where an XML absolute date and time value is used. This date and time value uses the zone offset to represent the distinction between the first occurrence of 2 AM and the second occurrence of 2 AM. The technique works because, during the Daylight Saving Time transitions, it is the time zone offset value that actually changes (since GMT never changes as a result of Daylight Saving Time).

Therefore, the first occurrence of fall 2 AM duplicate hour will be represented by an XML time and date value that shows the Daylight Saving Time zone offset which is usually 1 hour less than the standard time offset. For example, these two values might look like:

2003-10-26T02:00:00-04:00

2003-10-26T02:00:00-05:00

So that the distinguishing factor is that the time zone offset values are different.

This technique for representing the duplicate fall hour will only be used in a few rare situations calling for such a time. For example, if the termination time on an emergency operator message is during that hour (not likely).

4.9.4 XML Character Data, Markup, and Escaped Characters XML text consists of intermingled character data and markup. Markup takes the form of start-tags, end-tags, empty-element tags, entity references, character references, comments, and CDATA


38

section delimiters. Anything that is not markup is called character data of the XML document.

The ampersand character ( & ) and the left angle bracket ( < ) may appear in their literal form only when used as markup. These characters cannot appear in their literal form within character data.

If these characters are needed within character data, they must be escaped using either numeric character references or the strings “&” and “<” respectively for & and <. The right angle bracket may appear in character data in some circumstances but it is best to escape this character using “>” or the numeric escape equivalent.

For example, if an element calls for the specification of character data for a name for instance, that name cannot include any of the characters mentioned above. Consider the following:

<name>MW&MVAR</name>

This is illegal because the & sign must be escaped. The result is that the parser will see the & as an escape which means that the next few characters are sucked in and interpreted as special characters. The result is that the < and the / may be eaten by the parser and the resulting XML document is not well-formed.

<name>MW&MVAR</name>

This is the correct specification when the & sign is needed.

<name>MW and MVAR</name>

This is better yet, avoid the & character altogether.

The XML specification should be consulted for a more detailed explanation of the differences in handling character data, markup, entities, entity references and so on. Our motivation though is to create an XML Schema that will not result in any of these situations however that assumes that the user always does the right thing. This explanation is for those users who get caught doing the wrong thing.

4.9.5 XML Null Data Sometimes it is useful or required to submit null data or null element sets. The business rule interpretation of null is based on the message type and the element involved. In some usages, a null


39

inserts a null value into the database itself, overwriting any previous value that may be held by the database. In other usages, it may mean that a default value is to be supplied.

4.9.6 XML Absent Elements Some elements are optional. They may appear in the XML instance document or they may not. If they do not appear, the default handling is governed either by the XML Schema definition or the application. However, the default handling is always documented so that there is no confusion or interpretation difficulties.

If the XML Schema specifies a default value than that value is substituted just as if the element were specified with that value. If the XML Schema does not specify a default value then the handling of a missing element or attribute is dependent on the message type. The actual handling is described later for each message type when an optional element can be specified but a default value is not given.

4.9.7 XML Attribute and Element Ordering Elements appearing in MUI XML responses can be expected to appear in the same order in which they are defined in their respective <sequence> elements in the XML schema, however the MUI will not validate ordering of elements in submitted requests.

XML attribute ordering is irrelevant. Attributes will appear in a consistent order in MUI XML responses, but this order should not be used in any programmatic validation and no XML parsing interface should depend on the order of attributes, as there is no XML schema definitions allowing for a required attribute order.

4.9.8 Common Data Types The following table lists common data types used by the messages of this specification. These are the data types or data formats that are specified with each message type.

Data Type Name Description Boolean

This data type represents a Boolean value of true or false. This Boolean data value must obey the following constraint facets or value range: True is represented as “true” or “1” False is represented as “false” or “0” The Boolean value is determined by the XML Schema specification. It is defined as an XML


40

Data Type Name Description Schema data type.

Character(n) This data type specifies an arbitrary character string with a maximum of “n” characters. The maximum allowed character length is specified with the type. If (n) does not appear in the type, then the character data is determined by a small list of enumerated string values which are documented when they are used.

Complex Type This describes an XML type declaration that contains nested XML elements or other complex types. There is no character data defined for a complex type. Note: By character data, we mean the data between the opening and closing element tags. A complex type may include one or more attributes.

Control Area Name This data type specifies the name of a control area. Control area names correspond to the control area Tag_Code values specified in the NERC TSIN registry (e.g., KCPL for Kansas City Power & Light). The control area name is defined as a character string from 1 to 64 characters in length, but the NERC code for control areas is limited to 4 characters.

Counterparty Identity

This data type specifies a counterparty or resource name. MP names and resource names must be registered with SPP.

Counterparty Type (PLT,GEN,CLD,TC,RTO)

This data type specifies a counterparty or resource type. A counterparty is identified by the combination of its name (Counterparty Identity) and its type (Counterparty Type). Valid counterparty types are: • PLT – plant • GEN – generation unit • CLD – controllable load

• TC – transmission customer (currently defined as market participant)

• RTO – Regional Transmission Organization (SPP)

Date YYYY-MM-DD

This data type, specified normally via its default format is the XML Schema data type called date (note, lower case). This data type is used for all calendar dates and it is governed and defined by


41

Data Type Name Description the XML Schema Datatypes standard.

DateTime YYYY-MM-DDThh:mm:ss

This data type, specified normally via its default format, is the XML Schema data type called dateTime (note case). This data type is used for all values that represent a calendar date and time or whenever an absolute clock time is required. Note that the hour-ending or interval-ending codes (described below) are not considered clock times and therefore not represented by this data type. See other discussion (section 4.9.3) on the variations allowed on the format.

Hour Ending HH

This data type is a label used to represent the hour ending values. Each hour-ending is a one or two-digit code from 1 through 24. A leading zero is allowed for hours 1 through 9 in XML submissions, but leading zeroes will never be returned in XML responses from the MUI. The first hour-ending of the day, starting at Midnight, is designated as 1. The last hour-ending of the day, ending at Midnight, is designated as 24. Daylight Saving Time is handled in the spring by skipping the hour ending 2. In the fall, the duplicated hour is indicated by including the isDuplicateHour attribute (see discussion).

Integer(range) This data type represents a decimal integer of the given range. The range is specified either by defining the minimum and maximum values (inclusive) in the format of "MIN-MAX" or by defining the total digits allowed as in N. For example, the range specification using min to max might show up as: Integer(1-999) Integer(0-10) And, the range specification of total number of digits might be: Integer(10) Integer(3) Where the first example immediately above means a maximum of a 10-digit number is allowed and in the second example a maximum of a 3-digit number is allowed.

Interval Ending HHMM

This data type is a label used to represent the 5-minute interval ending values. Each 5-minute


42

Data Type Name Description interval is described by a 4-digit code ranging from 5 through 2400. Leading zeroes are allowed in XML submissions for interval values from 5 to 955, but leading zeroes will never be returned in XML responses from MUI. Note that the examples below are padded with leading zeroes for the purposes of readability. The intervals are identified as multiples of 5. For example, the first 4 intervals of the day are 0005, 0010, 0015, and 0020. Daylight Saving Time is handled in the spring by skipping the hour ending 0200 interval. In the fall, the duplicated hour is indicated by including isDuplicateHour attribute (see discussion). For example: The first intervals in the spring on the Daylight Saving Time transition day would appear as: 0005, …, 0055, 0100, 0105, …, 0155, 0300, 0305, and so on. The first intervals in the fall transition day would appear as: 0005, …, 0055, 0100, 0105, …, 0155, 0200, 0105, …, 0155, 0200, 0205, and so on. The italicized intervals in the example above are the second set (duplicate hour) and these intervals must also be described with the isDuplicateHour attribute set to "true".

Load Area Name This data type specifies the name of a load area. Load area names are defined by SPP. The name is defined as a character string from 1 to 64 characters in length.

Location Name This data type specifies a pricing node (pnode) name as a character string value. This corresponds to a settlement location. The maximum length of the location name is 64 characters.

MW This data type is used to represent capacity, limits, and energy values. This is an integer between -9999999 and 9999999, inclusive.

MW Rate This data type is used to represent a MW rate in units of MW per minute. This is a decimal number between -9999.99 and 9999.99, inclusive, with up to two digits to the right of the decimal point (i.e., with precision of .01 MW).


43

Data Type Name Description Nonnegative MW This is a specialization of the MW type described

above. It is an integer between 0 and 9999999, inclusive.

Price

This data type represents a price in $ or $ per MW depending on the context. The value is represented as decimal number between -99999999.99 and 99999999.99, inclusive, with up to two digits to the right of the decimal point (i.e., with precision of $.01).

Singleton Type This describes an XML type declaration that consists of attributes. It is considered by XML to be an empty tag. It has no character data or nested content.

Resource Identity This data type specifies a resource name on resource-specific messages. Resource names must be registered with SPP. The resource name is a character string from 1 to 64 characters in length.

Resource Type This data type specifies a resource type on resource-specific messages. A resource is identified by the combination of its name (Resource Identity) and its type (Resource Type). Valid resource types are: PLT – plant GEN – generation unit CLD – controllable load XGEN – generation unit external to the SPP footprint Note that resource types are a subset of counterparty types.

(a, b, c, …) This data type represents an enumerated list of values that are the allowed data values. The list is comma-separated and the values MUST BE specified exactly as they appear including proper case and spelling. Abbreviations are not recognized unless they too are specified as valid enumerated values. Each enumerated list is defined as it appears in the message description.

4.10 File Upload/Download Format The file upload/download XML format is identical to the message body of the HTTP requests or response. The only missing lines are those specifying HTTP headers and the SOAP wrapping. The


44

following example shows a query response as an HTTP message and the same query response formatted as a file.

First, the HTTP message query response8: HTTP/1.1 200 OK Content-Type: text/xml Content-Length: ddd <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <ASCapacityObligation day="2004-03-11"> … </ASCapacityObligation> </QueryResponse> </env:Body> </env:Envelope>

The equivalent file download format appears as shown below: <?xml version="1.0" encoding="UTF-8"?> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <ASCapacityObligation day="2004-03-11"> … </ASCapacityObligation> </QueryResponse>

Whether the message content is a QueryResponse (as shown in the example above), a QueryRequest, a SubmitRequest, or a SubmitResponse, the same rules apply in formatting the file.

The file is named according to the type of data but this name can easily be changed by the user as part of the download process therefore not much substance is given to the file names.

8 XML example is shown for illustrative purposes only, it does not necessarily refer to an actual message defined by this specification.


45

5. Data Submittal, Update, Delete This chapter describes the data submittal and update messages that are initiated by the MP. Submittal messages are formulated by the participant and sent to the RTO market server. In response, the RTO returns a transaction success or transaction error message. This submittal and response uses the request/reply messaging protocol described earlier.

Submitted data can be updated (replaced) by the participant as long as the window for that data type is still open to receive submittals. Some submitted data can also be deleted. When submitted data is deleted, it is just as if it were not submitted in the first place (except both submittal and delete are recorded as transactions). Once the window closes, submitted data cannot be updated nor can it be deleted.

The following table summarizes the data submittal messages described in this chapter. Note that the detail of each individual message is described in the chapter 9.

Each submittal type has restrictions on how early or late they can be submitted. In general these restrictions are documented in the Market Protocols document on SPP’s web site, however in special cases these times may be temporarily modified. In these cases MPs will receive new MarketSchedule notifications describing the new timelines, and the MarketSchedule data available through the MUI will be updated.

XML messages sent to SPP are subject to 4 stages of validation:

• XML Syntax – The first validation checks that the submission uses valid XML syntax.

• Namespaces – The second validation attempts to resolve the namespaces used in the document to their respective XML schemas in order to retrieve the rules of usage for the namespace-annotated XML elements.

• Schema – The third validation checks that the elements used in the XML submission conform to the rules defined in the schema in which the element is defined. See section 4.6 for the schemas used in MOS and their namespaces.

• Business Rules / Timeline – Once the message has been determined to be syntactically correct and valid according to the schema, it is validated against the business rules and submission timelines defined in the market database.


46

This document only fully addresses the first three stages of validation. Some general information is provided on how to successfully submit each message type, but for a complete definition of the business requirements consult the SPP Market Protocols document.

ASCapacityPlan

This message is used to submit AS capacity plan data. AS capacity plan data can be deleted or updated up to the submittal deadline.

EISOffer

This message is used to submit the energy imbalance service offer for the real-time balancing dispatch. EIS offer data can be deleted or updated up to the submittal deadline.

ResourcePlan

This message is used to submit resource plan data. Resource plan data cannot be deleted, but can be updated up to the submittal deadline.

ParticipantLoadForecast

This message is used to submit participant generated Load Forecast data. Participant Load Forecast data cannot be deleted, but can be updated up to the submittal deadline.

5.1 Data Submit Overview Data is submitted using the SubmitRequest message. A SubmitRequest message is designed to handle the submittal of any data type. Data replace and delete is also handled using the SubmitRequest. Each of these message types is described in overview in the following sections.

5.1.1 SubmitRequest Message The SubmitRequest may contain one or more instances of any of the messages named above. However, a SubmitRequest may contain multiple instances of only the same message type. If you wish to submit both a ResourcePlan and an ASCapacityPlan then these must be executed by separate SubmitRequest messages. The validation logic will ensure that only a single message type is submitted per SubmitRequest message.

Note: Extensive testing has shown conclusively that performance and reliability are optimum when only one instance of a given submittal type is used within a single SubmitRequest message. Using separate, smaller files rather than combining them all into a


47

single SubmitRequest element greatly decreases the chances of a communication failure due to a network bottleneck or a brief loss of connectivity. SPP will be monitoring XML transactions and working with participants to restructure excessively large XML files.

Example ASCapacityPlanSubmitRequest: <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <SubmitRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <ASCapacityPlan day="yyyy-mm-dd"> -- elements of capacity plan -- </ASCapacityPlan> <ASCapacityPlan day="yyyy-mm-dd"> -- elements of capacity plan -- </ASCapacityPlan> … </SubmitRequest> </env:Body> </env:Envelope>

When data is submitted, the participant client waits for the response message. This response message is synchronous and documented by the request/reply protocol described in chapter 3 of this specification.

The response message either indicates success (an ACK) or failure (a NAK). Success response messages for submittals (whether initial submit or replace action) returns the transaction identifier uniquely associated with the data set that is submitted (or, replaced).

If a failure is returned, then the error (or, errors) describing the problem are returned. Both submittal success response and submittal failure error response are contained in a message called <SubmitResponse> which is returned synchronously to the participant client software.

The following example shows the successful (ACK) response message including the transaction identifier. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <SubmitResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <Success> <TransactionID>0293894453</TransactionID> </Success> </SubmitResponse> </env:Body> </env:Envelope>


48

The submit response returning a transaction identifier returns one transaction identifier for the submitted data.

If the response included errors, then the error response is returned as shown in the example below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <SubmitResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <Error> <Code>ORA-20000</Code> <Text>Resource sss does not exist</Text> </Error> <Error> <Code>XMLEMKT-120</Code> <Text>Obligations and Resources do not balance for hour hh</Text> </Error> </SubmitResponse> </env:Body> </env:Envelope>

In this example above, two separate errors are returned to the client. The first error is raised by the Oracle software as shown by the error <Code> element. The second error is raised by the XML processing component as shown by the error code. These error codes are used internally only by the SPP help desk. They have no relevance or meaning to the participant. The participant derives all knowledge of the error condition from the textual description itself.

5.2 Submitting Ancillary Service Capacity Plan The ancillary service (AS) capacity plan shows the ancillary service capacity schedule of obligations and resources for all hours of the day.

An ancillary service capacity plan must be balanced. This means that for each hour, the total MW of capacity (for all ancillary service product types) of scheduled obligations must match the total MW capacity of scheduled resources. A plan that is not balanced will not be accepted by SPP.

An ancillary service capacity plan must be matched. Matching ensures that a scheduled resource of the submitter is a scheduled obligation of the counterparty and vice versa. Matching determines that the MW capacity for the hour and the product type match between party and counterparty. If a schedule is not matched, then a MismatchASCapacityPlan message is sent for each unmatched hour and service to both the party and the counterparty.


49

After receiving the mismatch notification messages (or, after receiving by query) the participant has until the submission deadline9 to update the ancillary service capacity plan to fix the unmatched entries. The party and counterparty must coordinate among themselves as to who is responsible for updating the plan. A plan may be fixed by only one party executing the update or it may require both parties to execute a plan update.

The operator may be required to override an ancillary service capacity plan by changing a MW value or some other value. When the operator makes such an override, a notification message is sent to the participants that are parties to the capacity plan to alert them to the change. This notification message is the OperatorOverride message described in chapter 9.

In order to submit an AS capacity plan for a given day and hour, a resource plan must first exist for each scheduled resource for the same day and hour (see section 5.4).

5.2.1 Submit Description The ancillary service capacity plan is submitted using the SubmitRequest message as shown by the following example. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <SubmitRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <ASCapacityPlan day="2004-03-10"> -- elements of capacity plan -- </ASCapacityPlan> <ASCapacityPlan day="2004-03-10"> -- elements of capacity plan -- </ASCapacityPlan> … </SubmitRequest> </env:Body> </env:Envelope>

In the above example, the actual ASCapacityPlan data is described in chapter 9. The response to the message is described above showing the transaction success or error failure response.

Instances of the ASCapacityPlan can be repeated for the same day or multiple days per the business rules documented by SPP10. Or, if only a single day is being submitted, all schedules can be submitted by a single instance of the ASCapacityPlan. Every

9 See SPP Market Protocols document (referenced in section 2.5) and MarketSchedule notification for up to date timeline information 10 See SPP Market Protocols document (referenced in section 2.5) for valid submittal times and validation calculations for AS capacity plans


50

instance of the ASCapacityPlan though must be balanced as described in section 5.2.

5.2.2 Replace and Delete Description The ancillary service capacity plan data can be replaced in whole or in part. If only a single hour needs to be replaced then only that hour need be included in the submittal. The SubmitRequest is formatted identically to the example shown above.

The following example shows the submittal of only a single hour and schedule. Note however that the plan must balance, even for an update replacement type submittal. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <SubmitRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <ASCapacityPlan day="2004-03-10"> <ASCapacityPlanHourly hour="4"> <ASService product="SUPP" controlArea="CA1"> <Schedule> <ASScheduleCode>Obligation</ASScheduleCode> <MW>56</MW> <Counterparty>TC1</Counterparty> <CounterpartyType>TC</CounterpartyType> </Schedule> </ASService> <ASService product="SUPP" controlArea="CA1"> <Schedule> <ASScheduleCode>Resource</ASScheduleCode> <MW>30</MW> <Counterparty>GEN1</Counterparty> <CounterpartyType>GEN</CounterpartyType> </Schedule> <Schedule> <ASScheduleCode>Resource</ASScheduleCode> <MW>26</MW> <Counterparty>GEN2</Counterparty> <CounterpartyType>GEN</CounterpartyType> </Schedule> </ASService> <ASCapacityPlanHourly> </ASCapacityPlan> </SubmitRequest> </env:Body> </env:Envelope>

To delete a schedule, you must delete all schedules for a given hour. This is accomplished by submitting an empty hourly element as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <SubmitRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <ASCapacityPlan day="2004-03-10">


51

<ASCapacityPlanHourly hour="12"/> </ASCapacityPlan> </SubmitRequest> </env:Body> </env:Envelope>

The above example shows that the schedules for the hour ending at 12 are to be deleted. You can delete other hours by repeating the ASCapacityPlanHourly element. Notice that the hourly element is empty as shown by the closing /> on the element. This can equally be accomplished as shown below. <ASCapacityPlanHourly hour="12"> </ASCapacityPlanHourly>

5.3 Submitting Energy Imbalance Service Offer An energy imbalance service offer is the offer curve for each hour that a resource is available for dispatch by SPP. The offer curve consists of at least two price points and no more than 10 price points. The offer curve MW and price values must be submitted in monotonically increasing order. MW values must be nonnegative (zero or greater), but price values may be negative.

The energy imbalance service offer does not need to include an offer curve for all hours of the day. Hours that are not included do not specify an offer.

The offer curve is entered as a series of MW-Price points as a strictly monotonically increasing curve spanning 0 MW to the maximum MW declared by the offer. If an explicit point including the 0 MW value is not included, then a 0 MW value at the lowest Price of the submitted offer curve is assumed. Strictly monotonically increasing means that each MW value for a price point must be greater than the previous MW value and each corresponding price value must be greater than the previous price value.

The offer curve is used in the calculation necessary for deployment and the resulting locational imbalance price. The set of price points that are submitted are used as the beginning and ending values for calculating a linear slope for each set of beginning and ending values. Therefore, each MW between the two price points has a different price due to the interpolation of the submitted price points. The last price point on the offer curve is used for all MWs between that point and the maximum economic capacity derived from the resource and ancillary service capacity plans if the maximum economic capacity is greater than the last MW value on the offer curve.


52

The EISOffer message must be submitted prior to market close11 .

5.3.1 Submit Description The following example shows the submittal of an offer for two hours. Note that in this example, several hours are skipped. These skipped hours do not contain an offer, and will not be modified by this message. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <SubmitRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <EISOffer resource="GEN1" type="GEN" day="2004-03-10"> <EISOfferHourly hour="13"> <EISOfferCurve> <EISOfferCurvePoint> <MW>0</MW> <Price>10.00</Price> </EISOfferCurvePoint> <EISOfferCurvePoint> <MW>100</MW> <Price>15.00</Price> </EISOfferCurvePoint> <EISOfferCurvePoint> <MW>150</MW> <Price>20.00</Price> </EISOfferCurvePoint> </EISOfferCurve> </EISOfferHourly> <EISOfferHourly hour="17"> <EISOfferCurve> <EISOfferCurvePoint> <MW>0</MW> <Price>10.00</Price> </EISOfferCurvePoint> <EISOfferCurvePoint> <MW>100</MW> <Price>15.00</Price> </EISOfferCurvePoint> <EISOfferCurvePoint> <MW>150</MW> <Price>20.00</Price> </EISOfferCurvePoint> </EISOfferCurve> </EISOfferHourly> </EISOffer> </SubmitRequest> </env:Body> </env:Envelope>

5.3.2 Replace and Delete Description When an EIS offer curve is submitted for an hour, it will replace in whole any existing offer curve for that hour. This means that if you

11 See SPP Market Protocols document (referenced in section 2.5) and MarketSchedule notification for up to date timeline information


53

want to modify an offer curve with multiple price points you cannot update an individual price point by submitting an offer curve containing only that point. If you did, it would result in the entire curve being replaced with just the one point that you submitted. Instead you must resubmit the entire offer curve including the point you want to update.

The hour elements behave differently from price points in that they can be replaced individually as seen in the example in section 5.3.1. When that example is submitted, only the specified hours will be modified.

To delete an offer for a given hour, you submit an empty EISOfferHourly element. The following examples shows the deletion of an outstanding offer for hour 13. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <SubmitRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <EISOffer resource="GEN1" type="GEN" day="2004-03-10"> <EISOfferHourly hour="13"/> </EISOffer> </SubmitRequest> </env:Body> </env:Envelope>

The above message submittal will delete any offer curve specified for hour ending 13. You may delete multiple hours by repeating the empty hourly element for each desired hour. To delete all hours of an entire day, you must submit an empty hourly element for each hour in the day.

5.4 Submitting Resource Plan The resource plan defines a resource’s status, planned generation, min/max MW ratings and ramp rate profile for a given day, hour and mode of operation (economic vs. emergency). A resource plan must be submitted for an hour prior to submitting an EIS offer curve or an AS capacity plan for that hour.

The resource plan that has been submitted is used to validate the ancillary service capacity plan and to ensure that the resource plan is complete. Resource plans are validated automatically, and then it may be validated again later by manual operator request. A resource plan is considered invalid if any of the conditions below exist:

• A resource plan is considered invalid if any hours of the day do not have a plan. All hours must have a plan.


54

• A resource plan is considered invalid if the determination of the plan as compared to the AS capacity plan demonstrates a PlanMW value that is too high or too low compared to the reserves that are set-aside in the A/S Capacity Plan12.

If a plan is determined to be invalid then an InvalidResourcePlan notification message is sent to the submitting MP at 1100 and 1300 day-ahead of the operating day and 45 minutes before the start of each operating hour the plan is determined to be invalid13. The MP is expected to resubmit a plan that resolves the problems. If the MP submits their corrections at least one hour before the submission deadline14, the corrected resource plan will be validated at least one more time before the submission deadline passes, giving the MP another chance for corrections. Resource plans are validated every hour, so for each hour between the current time and the deadline the MP would be able to see the result of a validation attempt on a corrected resource plan. An operator could also override this schedule and run a manual resource plan validation if necessary, resulting in an additional notification message.

Once the deadline has passed, if the resource plan needs correction the operator would have to override it. This will result in an OperatorOverride notification message being sent to the MP who submitted the resource plan. See chapter 9 for more information on this message.

5.4.1 Submit Description The following example shows a typical submittal for a single resource. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <SubmitRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <ResourcePlan resource="GEN1" type="GEN" day="2004-01-01"> <ResourcePlanHourly hour="1"> <ResourceStatus>Available</ResourceStatus> <PlanMW>120</PlanMW> <MinMW>20</MinMW> <MinEconomicMW>20</MinEconomicMW> <MinEmergencyMW>20</MinEmergencyMW> <MaxMW>180</MaxMW> <MaxEconomicMW>180</MaxEconomicMW> <MaxEmergencyMW>180</MaxEmergencyMW>

12 See SPP Market Protocols document (referenced in section 2.5) for details on resource plan validation calculations 13 See SPP Market Protocols document (referenced in section 2.5) for up to date timeline information 14 See SPP Market Protocols document (referenced in section 2.5) and MarketSchedule notification for up to date timeline information


55

<RampRateProfile> <RampRateBreakpoint> <BreakpointLimit>0</BreakpointLimit> <RampRateUp>10</RampRateUp> <RampRateDown>10</RampRateDown> <RampRateEmergency>15</RampRateEmergency> </ RampRateBreakpoint> <RampRateBreakpoint> <BreakpointLimit>50</BreakpointLimit> <RampRateUp>15</RampRateUp> <RampRateDown>15</RampRateDown> <RampRateEmergency>20</RampRateEmergency> </ RampRateBreakpoint> </RampRateProfile> </ResourcePlanHourly> <ResourcePlanHourly hour="2"> <ResourceStatus>Available</ResourceStatus> <PlanMW>120</PlanMW> <MinMW>20</MinMW> <MinEconomicMW>20</MinEconomicMW> <MinEmergencyMW>20</MinEmergencyMW> <MaxMW>180</MaxMW> <MaxEconomicMW>180</MaxEconomicMW> <MaxEmergencyMW>180</MaxEmergencyMW> <RampRateProfile> <RampRateBreakpoint> <BreakpointLimit>0</BreakpointLimit> <RampRateUp>10</RampRateUp> <RampRateDown>10</RampRateDown> <RampRateEmergency>15</RampRateEmergency> </ RampRateBreakpoint> <RampRateBreakpoint> <BreakpointLimit>50</BreakpointLimit> <RampRateUp>15</RampRateUp> <RampRateDown>15</RampRateDown> <RampRateEmergency>20</RampRateEmergency> </ RampRateBreakpoint> </RampRateProfile> </ResourcePlanHourly> </ResourcePlan> </SubmitRequest> </env:Body> </env:Envelope>

Only the first two hours are shown but all hours for the day may be included. To submit other days for the same resource, you must include other instances of the <ResourcePlan> or send a separate request. Resource plans are not carried forward.

5.4.2 Replace Description Resource plan data may be replaced but it cannot be deleted. All resources must have a plan for all hours so there is little benefit in deleting a plan. To replace a plan, you merely need to resubmit the plan as shown in the above example. You may replace only the hours need as shown below where only hour 4 is replaced, the other hours are left alone. <?xml version="1.0" encoding="UTF-8"?>


56

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <SubmitRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <ResourcePlan resource="GEN1" type="GEN" day="2004-01-01"> <ResourcePlanHourly hour="4"> <ResourceStatus>Available</ResourceStatus> <PlanMW>120</PlanMW> <MinMW>20</MinMW> <MinEconomicMW>20</MinEconomicMW> <MinEmergencyMW>20</MinEmergencyMW> <MaxMW>180</MaxMW> <MaxEconomicMW>180</MaxEconomicMW> <MaxEmergencyMW>180</MaxEmergencyMW> <RampRateProfile> <RampRateBreakpoint> <BreakpointLimit>0</BreakpointLimit> <RampRateUp>10</RampRateUp> <RampRateDown>10</RampRateDown> <RampRateEmergency>15</RampRateEmergency> </ RampRateBreakpoint> <RampRateBreakpoint> <BreakpointLimit>50</BreakpointLimit> <RampRateUp>15</RampRateUp> <RampRateDown>15</RampRateDown> <RampRateEmergency>20</RampRateEmergency> </ RampRateBreakpoint> </RampRateProfile> </ResourcePlanHourly> </ResourcePlan> </SubmitRequest> </env:Body> </env:Envelope>

Note that you must specify all elements contained by the hourly element. You cannot merely replace PlanMW by submitting that value alone. That would be declared invalid XML since this would violate the XML Schema.

5.5 Submitting Participant Load Forecast Participant Load Forecast defines an MP generated Load Forecast for a given day and hour. MPs may only submit Load Forecast data for Control Areas in which they have at least one load asset.

The Participant Load Forecast data that has been submitted is validated against submitted Resource Plan and energy schedule15 data to ensure that sufficient capacity is available to meet the forecasted amount, and that an excess of capacity is not supplied.

If a capacity over/undercommitment is detected, then an OverUnderCommitment notification message is sent to the submitting MP. This validation is performed at 1100 and 1300 for

15 Energy Schedule data is submitted via the RTOSS interface. See SPP Market protocols document (referenced in section 2.5) for more information.


57

the next operating day and 45 minutes before the start of each operating hour for the next 1.5 operating hours. Notifications may also result from operator executed manual validations that may occur at any time. If the MP submits revised Resource Plan, Energy Schedule or Load Forecast data at least one hour before the submission deadline16, the new data will be validated at least one more time before the submission deadline passes, giving the MP another chance for revisions.

See section 9.18 for more information on the OverUnderCommitment notification message and the calculations used to determine that an over/under commitment exists.

5.5.1 Submit Description The following example shows a typical submittal for a multiple hours and Control Areas. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <SubmitRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <ParticipantLoadForecast day="2004-01-01"> <ParticipantLoadForecastHourly hour="1"> <ParticipantLoadForecastDetail> <ControlArea>CA1</ControlArea> <ForecastMW>150</ForecastMW> </ParticipantLoadForecastDetail> <ParticipantLoadForecastDetail> <ControlArea>CA2</ControlArea> <ForecastMW>125</ForecastMW> </ParticipantLoadForecastDetail> </ParticipantLoadForecastHourly> <ParticipantLoadForecastHourly hour="2"> <ParticipantLoadForecastDetail> <ControlArea>CA1</ControlArea> <ForecastMW>150</ForecastMW> </ParticipantLoadForecastDetail> <ParticipantLoadForecastDetail> <ControlArea>CA2</ControlArea> <ForecastMW>125</ForecastMW> </ParticipantLoadForecastDetail> </ParticipantLoadForecastHourly> </ParticipantLoadForecast> </SubmitRequest> </env:Body> </env:Envelope>

Only two hours are shown but a submittal can contain hours for the entire day. To submit Load Forecast for other days, you must include other instances of the <ParticipantLoadForecast> element

16 See SPP Market Protocols document (referenced in section 2.5) and MarketSchedule notification for up to date timeline information


58

or submit a separate request. Participant Load Forecast data is not carried forward.

5.5.2 Replace and Delete Description Participant Load Forecast data may be replaced but it cannot be deleted. To replace a Load Forecast for a certain hour and Control Area, you can submit only that hour and Control Area as shown in the example below. The response to this example will be to replace data for only the specified Control Area and hour – all other existing data will be left alone. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <SubmitRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <ParticipantLoadForecast day="2004-01-01"> <ParticipantLoadForecastHourly hour="1"> <ParticipantLoadForecastDetail> <ControlArea>CA1</ControlArea> <ForecastMW>150</ForecastMW> </ParticipantLoadForecastDetail> </ParticipantLoadForecastHourly> </ParticipantLoadForecast> </SubmitRequest> </env:Body> </env:Envelope>


59

6. Notification Messages Notification messages are messages sent by SPP to individual MPs who have registered their message listener with SPP. These messages are described in the following table.

ASCapacityObligation Notification of MP's ancillary service capacity obligation. These messages are sent no later than 0730 on the day ahead of the operating day17. In the event that obligations are loaded more than once in a single day, an ASCapacityObligation message will be sent each time the obligations are loaded.

Dispatch Notification of energy imbalance service (EIS) and out-of-merit energy (OOME) dispatch instructions. These messages are sent for each dispatch interval during real-time on the operating day.

MarketSchedule Notification of the current energy imbalance service market schedule and day-ahead capacity analysis timeline events. These messages are sent as needed by operator commanded update of the market schedule.

MismatchASCapacity Plan

Notification of capacity plan mismatch sent to both parties of a capacity plan that is in disagreement between party and counter party. This message is sent when the imbalanced plan is submitted.

EISOfferCapEnabled Notification of the enabling of an EIS offer cap on a resource sent to the owner of the resource.

EISOfferCapDisabled Notification of the disabling of an EIS offer cap on a resource sent to the owner of the resource.

EISOfferCap Notification of EIS offer cap data by resource sent to the owner of the resources.

URDResourceLocked Notification of the lockout of a resource

17 See SPP Market Protocols document (referenced in section 2.5) for up to date timeline information


60

due to URD violations sent to the owner of the participant.

ReturningURDLockedResource

Notification of a locked resource that is a configured number of intervals from being unlocked.

URDResourceUnlocked Notification of the release of a previously locked out resource sent to the owner of the resource.

URDInterval Notification of the results of a URD calculation for a given dispatch interval and resource sent to the owner of the resource.

SelfDispatchMinViolation Notification of failure of a SD resource to pass validation against Resource Plan data due to not meeting the calculated minimum MW. Message is sent to the owner of the SD resource.

SelfDispatchMaxViolation Notification of failure of a SD resource to pass validation against Resource Plan data due to exceeding the calculated maximum MW. Message is sent to the owner of the SD resource.

InvalidResourcePlan Notification of invalid resource plan sent to participants whose resource plan is found to be invalid or missing.

OperatorMessage Notification of operator event such as an emergency condition.

OperatorOverride Notification of an operator data override to an AS capacity plan or resource plan.

OverUnderCommitment Notification of a mismatch between Participant Load Forecast, Resource Plan and energy schedule data indicating a capacity over/undercommitment

DeliverabilityAnalysis Indicates anticipated locations of congestion and the degree to which the congestion is expected to be from economic dispatch efficiencies over the planned MW or if the plan itself results in redispatch to become feasible.For infeasible solutions, market participant impacts on constraints are identified.

ViolationRelaxationLimit Indicates one of the following limits was relaxed while solving a real-time balancing (RTB) interval:


61

• Operational Constraint • Ramp Rate • Load/Gen Balance • Capacity The message specifies the limit type, the related entity, and the violation MW amount.

CalculatedCurtailmentLevel

This is a notification of calculated curtailment limit immediately following receipt of information from CAT. Sent each time RTB study is approved. The notifications are sent to the resources where there is a CalculatedCurtailment value. Each MP is sending the notifications for resources which they own.

Ping A special test message sent to participant web listeners to determine the operation of the link to the participant. May be issued periodically or by operator demand.

6.1 Notifications Overview Notification messaging is discussed below with respect to the RTO sending messages and the MP listening for messages.

6.1.1 Notifications Messaging A notification message is sent to individual registered MPs using the same SOAP/web service mechanism used by the MUI, but in the opposite direction. In this case the RTO’s Notification server is the client, and the server resides with the MP. The RTO formulates the message, connects to the participant's web service, and sends the message. After sending the message, the RTO waits for the participant's response. After the response is received the operation is finished and the connection to the participant's web listener is closed.

Like the MUI, Notifications uses SSL and digital certificates. The difference, as mentioned above, is that in this case Notifications is the client, and presents the digital certificate to authenticate itself to the MP’s web service. All of the same information in chapters 3 and 4 applies to this communication, just the directionality is reversed.


62

All notification messages sent to the participant are formatted as a SOAP wrapped message where the root element under the SOAP <Body> is the <Notifications> element.

The following example shows an Operator message formulated as a notification. This is the message packet that would be received by the participant's web listener. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <Notifications xmlns="http://emkt.spp.org/2004/emkt/xml"> <OperatorMessage> …data… </OperatorMessage> </Notifications> </env:Body> </env:Envelope>

The <Notifications> element may contain more than one instance of a single message type (e.g. OperatorMessage).

When the participant receives the notification message a response must be sent back to the RTO synchronously. This response merely indicates whether the notification message was received correctly. It does not mean that the deployment instruction was executed or that the obligation is accepted by the participant or that an operator message is understood and acted upon. It only means that the message was received correctly without transmission or formatting errors.

A successful response is returned when:

1 The message was received without errors (TCP or other network communications).

2 The XML message parses correctly and validates correctly according to the schema

An error response is returned when:

1 The message is not received in total (byte count error, CRC error, other communications error).

2 The XML message does not parse or it does not validate correctly.

The following example shows a successful response. This message is returned by the participant when the success criteria (mentioned above) has been met. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">


63

<env:Body> <NotificationSuccess xmlns="http://emkt.spp.org/2004/emkt/xml"/> </env:Body> </env:Envelope>

This message merely reports that the notification message was received without problems. If any error occurs or any other event that prevents the full understanding of the message, the failure message as shown below is returned. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <NotificationFailure xmlns="http://emkt.spp.org/2004/emkt/xml"/> </env:Body> </env:Envelope>

Note that the notification failure message response above does not describe the cause or reason for the failure. It notifies the RTO that the connection to the web service was made successfully, but either the message was not interpreted correctly or an internal server error occurred. Web listeners are recommended, not obligated to respond with NotificationFailure responses in these cases. It helps the RTO to diagnose a problem when errors are reported more accurately

There are other notification sending errors that can occur though that the participant may not know about. For example, if the participant's web listener is down for maintenance or inoperational for some reason, the message will not be received. The RTO will either get an error during the connection request handshake or it will receive a timeout18 notice from TCP/IP on the connection. These types of errors are received and logged by the RTO but they do not involve the participant directly, as they indicate a failure to even reach the MP’s web service endpoint. In these cases the response would have either not been retuned at all, or returned from an upstream server reporting an error in locating the web service endpoint.

6.1.2 Listening For Notification Messages To receive notification messages a participant must register a web listener with SPP. The web listener has the following attributes:

• Web listener is a web service, compliant with the specification for SOAP 1.0 or 1.1 web services19. A web service can be hosted inside an existing web container or HTTP server such as

18 The currently configured timeout for connecting to a MP’s web service is 15 seconds. 19 See chapters 3 and 4 and the recommended text and documents for more information on the SOAP web service specification


64

implemented by Apache HTTP Server, products such as Sun Microsystems iPlanet or Microsoft IIS. A web listener can also be custom code that sets up a TCP/IP server socket to listen for connections, so long as it is prepared to receive requests based on the SOAP specification.

• Web listener must accept SSL connections (i.e. HTTPS) using digital certificates for authentication of the server publishing the notification.

• The server’s trust store must include the root certificate for the CA specified by SPP, and the web server must be configured to grant access to the notification server certificate.

• The server’s digital certificate must be signed by a CA that is recognized by SPP, or the participant must send their signing CA’s root certificate to SPP to be added to the Notification server’s trust store.

• SPP will provide the CA root certificate for the CA that signed the Notifications client certificate.

• The CRL for this CA will also be made available for web servers that choose to make use of it.

• If the web listener filters access based on certificate field values, SPP will provide the values from the Notification client certificate fields so that these tests can be performed.

• Participant must register a URL with SPP. This single URL is the address of the participant's web listener. The required URL address is described below.

The web listener listens for the notification message and responds to all messages as described previously. Typically the steps involved depend on the software approach chosen by the participant. Individual steps are highlighted below:

• Receive the HTTPS message (this step is handled by the HTTP server).

• Parse the XML (validate syntax)

• Validate the XML against the schema

• Respond to message with Success or Failure response.

• Perform appropriate actions based on the message content

Note that the execution of the message is outside of the bounds of the message communication. The response should be sent before


65

the execution so that response is sent as quickly as possible. SPP gathers statistics on web service response times for diagnostics, and any delay not related to the initial message exchange would invalidate these statistics. The web listener must respond within the configured timeout interval for Notifications.20

Listener URL Address Format

The URL address must be defined according to the URL naming standard. This basic standard appears as: https://<host-computer>[:port]/<path>

Where <host-computer> name is specifies as a recognized DNS host name or an IP address. The port number is optional. For HTTPS the default port is 443 although you may listen at any other port if it is specified in the URL registered with SPP. The <path> specifies any legal path along with any parameters desired. Note that this path and the parameters, if included, are fixed and constant for all messages.

The following examples show valid listener URL addresses:

https://listener.cleanpower.com/SPPListen/xml https://68.20.2.6:9000/ https://host.reliableenergy.org/listener/xml/fine/path/detail/to/use

6.1.3 Multiple Notifications Listeners Market participants may register multiple URLs for the purposes of redundancy or proxying notifications to an external party on whose behalf they are participating in the market. The following types of URLs may be registered:

• Primary (minimum of 1, maximum of 1) - Primary URL for the participant

• Secondary (maximum of 1) – Secondary URL for redundancy

• Additional (maximum of 8) – Additional URLs for further redundancy or for proxying notifications to a third party.

Notifications will be delivered first to the primary listener, then to the secondary listener, then to each additional listener. The order in which notifications are delivered to additional listeners is not guaranteed.

20 Currently 15 minutes


66

6.1.4 Notifications Retry To achieve a higher rate of successful delivery the notifications system will retry notifications that fail for reasons indicating an HTTP communication error. Notifications will be retried up to five times before they are abandoned. Retries will only be attempted for listeners defined as the primary listener for a participant. Notifications sent to secondary or additional listeners will not be retried.

6.2 Notification Message Schema Template As already described, all notification messages are contained in the <Notifications> element which appears under the SOAP <Body> element. The general message template is shown below. <Notifications xmlns="http://emkt.spp.org/2004/emkt/xml"> <message-type> …data… </message-type> </Notifications>

Only one instance of the <Notifications> element will be specified in the SOAP <Body>. All messages sent to the web listener URL are notifications messages that obey the semantics and format of messages documented in this specification. This URL will not receive any other kind of message from the RTO.

<message-type> is one or more of the following message types:

<ASCapacityObligation>

<Dispatch>

<EISOfferCap>

<EISOfferCapEnabled>

<EISOfferCapDisabled>

<InvalidResourcePlan>

<MarketSchedule>

<MismatchASCapacityPlan>

<OperatorMessage>

<OperatorOverride>

<Ping>

<SelfDispatchMinViolation>


67

<SelfDispatchMaxViolation>

<URDInterval>

<URDResourceLocked>

<ReturningURDLockedResource>

<URDResourceUnlocked>

<OverUnderCommitment>

<DeliverabilityAnalysis>

<ViolationRelaxationLimit>

<CalculatedCurtailmentLevel>

Where each of these message formats are documented in chapter 9 of this specification.

These messages may appear in any order and any number. The <Notifications> element will never itself be empty. If there is nothing to be sent, no <Notifications> message is sent. Some of the messages, such as <Dispatch> are sent on periodic intervals. Other messages are sent only at a certain time of the day (e.g. <ASCapacityObligation>), and other messages are sent by special event (e.g. <MismatchCapacityPlan> when a plan suffers mismatch problems), and other messages are sent by operator request (e.g. OperatorMessage, Ping).

In all cases, the <Notifications> element can be expected to encapsulate the largest possible amount of data for a given message type in a single XML transmission. If multiple notifications result from a single trigger, action or scheduled event only one XML message will be sent. This may be accomplished through multiple instances of a particular message type element (e.g. Dispatch), or through multiple instances of a message type’s child elements (e.g. ASObligationHourly). Note that some message types can appear both as a result of a scheduled event and by exception (e.g. EIS vs. OOME Dispatch), so they may at times be communicated in bulk and other times be sent in single instances.

The following example shows a notification message that includes two instances of OperatorMessage. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <Notifications xmlns="http://emkt.spp.org/2004/emkt/xml">


68

<OperatorMessage> <EffectiveTime>2004-03-01T12:00:00.000-06:00</EffectiveTime> <TerminationTime>2004-03-02T12:00:00.000-06:00</TerminationTime> <Priority>1</Priority> <Realm>Public</Realm> <Text>Emergency Conditions in force for next 24 hours</Text> </OperatorMessage> <OperatorMessage> <EffectiveTime>2004-03-01T12:00:00.000-06:00</EffectiveTime> <TerminationTime>2004-03-01T12:30:00.000-06:00</TerminationTime> <Priority>999</Priority> <Realm>Public</Realm> <Text>Pizza is in the lunchroom</Text> </OperatorMessage> </Notifications> </env:Body> </env:Envelope>

Other instances of notification messages follow the same general rule and according to the message format as described in chapter 9 of this specification.

6.3 Ping Notification Message The Ping notification message does not convey any data to the participant. Instead, it is used to test the operation of the notification sender and the network path to the participant's web listener and the web listener basic operation.

The Ping notification message may be sent periodically per an operator entered schedule or by operator demand. The proper response of the Ping notification message is to return the <NotificationSuccess> as described in section 6.1.1 of this document.

The kinds of tests that are performed include the following. In each case, the description below assumes a Ping message sent to the participant listener registered URL.

1 Message listener timeout will occur for a number of causes. These include: URL is not correct, Message Listener is not actively listening, Message listener is not responding in any way to the TCP/IP connection. This error is raised by the TCP/IP protocol stack when a valid connection cannot be made.

2 Message TCP/IP error response may occur in some situations where the TCP/IP stack on the participant's web listener deems there to be an error or problem.


69

3 Premature closure or dropping the link type error may be raised if the web listener software makes the appropriate connection but fails to respond with the appropriate ACK or NAK response message.

4 The Ping message is received by the participant web listener but it does not parse as correct XML according to the known format of a <Ping> element. In this situation, the data may have been garbled or the web listener may have an incorrect or out of date XML Schema. In this situation, the web listener should be designed to return the <NotificationFailure> NAK response.

5 The Ping message may be received by the participant web listener without error but for some other reason, the participant wishes the web listener to be considered as non-functional. For example, if the connection is successful and the XML is processed without error, but there is some other failure in the back-end software that renders the web service essentially non-functional. In this case, the <NotificationFailure> NAK response should be returned.

In each of the above failure scenarios, The failure is logged in a statistics gathering system. These statistics will be periodically reviewed by SPP, who will notify the MP of the issue upon discovering it.


70

7. Data Query The data query request message is used to query market data. Market data that is available for query includes data submitted by the participant, market results private to individual participants, published data available to all participants, and notification messages sent to all or specified MPs.

There is also a query for transaction request message documented in a later chapter of this specification.

Various data sets published by SPP are available at different times of the day. Some data is available throughout the day whereas other data is available as a result of a market timeline event. The market events that specify the availability of the data is noted for each individual message type documented in chapter 9.

The following table summarizes the available data query by the type of query issued. The names appearing in the left hand column in the table below are the query message names as documented in this chapter. The right hand column specifies the query type with respect to the kind of parameters used in specifying the query request.

QueryASCapacityObligation QueryAllEISOffer QueryAllEnergyLMP

Query Type: by date, and optionally by hour. These messages are queried by specifying the operating day date, and optionally the operational hour-ending period. If the hour is not specified, the behavior is to return all available data for all hours of the day.

QueryASCapacityPlan Query Type: by date, and optionally by hour, product code, and control area. These messages are queried by specifying the operating day date, and optionally the operational hour-ending period, ancillary service product code, and control area. If the hour is not


71

specified, the behavior is to return data for all hours of the day. If the product code is not specified, the behavior is to return data for all ancillary service product codes. If the control area is not specified, the behavior is to return data for all control areas.

QueryEISOffer QueryResourcePlan

Query Type: by resource, type, date, and optionally by hour. These messages are queried by specifying the associated resource identifier, resource type, the operating day date, and optionally the operational hour-ending period. If the hour is not specified, the behavior is to return all available data for all hours of the day.

QueryEnergyLMP Query Type: by settlement location, location type, date, and optionally by hour. These messages are queried by specifying the associated settlement location identifier, location type, the operating day date, and optionally the operational hour-ending period. If the hour is not specified, the behavior is to return all available data for all hours of the day.

QueryParticipantLoadForecast

Query Type: by date, and optionally by hour and control area. These messages are queried by specifying the operating day date and optionally the operational hour-ending period and control area. If the hour is not specified, the behavior is to return all available data for all hours of the day. If the control area is not specified, the


72

behavior is to return data for all control areas.

QueryOverUnderCommitment Query Type: by date, and optionally by interval and control area. These messages are queried by specifying the operating day date and optionally the operational interval-ending period and control area. If the interval is not specified, the behavior is to return all available data for all intervals of the day. If the control area is not specified, the behavior is to return data for all control areas.

QueryMidtermLoadForecast QueryShorttermLoadForecast

Query Type: by date, and optionally by hour and load area. These messages are queried by specifying the operating day date and optionally the operational hour-ending period and load area. If the hour is not specified, the behavior is to return all available data for all hours of the day. If the load area is not specified, the behavior is to return data for all load areas.

QueryCurrentEISOfferCap QueryCurrentURDResourceLocked QuerySelfDispatchMinViolation QuerySelfDispatchMaxViolation

Query Type: by resource and type. These messages are queried by specifying the resource and resource type. Both parameters are required.

QueryDeliverabilityAnalysis Query Type: by day and optionally by hour, constraint and/or eventID

QueryDispatch Query Type: by resource, type, date, and optionally by dispatch interval and dispatch type.


73

These messages are queried by specifying the associated resource identifier, resource type, the operating day date, and optionally the interval-ending period and the dispatch type. If the dispatch interval is not specified, the behavior is to return dispatches for all intervals of the day. If the dispatch type is not specified, the behavior is to return dispatches of all types.

QueryURDInterval Query Type: by resource, type, date, and optionally by dispatch interval. These messages are queried by specifying the associated resource identifier, resource type, the operating day date, and optionally the interval-ending period. If the dispatch interval is not specified, the behavior is to return records for all intervals of the day.

QueryAllURDInterval Query Type: by date, and optionally by dispatch interval. These messages are queried by specifying the operating day date, and optionally the interval-ending period. If the dispatch interval is not specified, the behavior is to return records for all intervals of the day.

QueryAllDispatch

Query Type: by date, and optionally by dispatch interval and dispatch type. These messages are queried by specifying the operating day date, and optionally the interval-ending period and the dispatch type. If the dispatch interval is not specified, the behavior is to return


74

dispatches for all intervals of the day. If the dispatch type is not specified, the behavior is to return dispatches of all types.

QueryOperatorMessage Query Type: by effective date and time and priority. The operator message is queried by the effective time of the message or by default by current time as effective time. The priority can be specified to filter the messages by priority code.

QueryOperatorOverride Query Type: by effective date and time of override, by plan type, by hour, and date of plan. The operator override is queried by the issue date and time of the message or by a combination of other query request parameters as defined.

QueryMarketSchedule QueryMismatchASCapacityPlan QueryInvalidResourcePlan QueryAllCurrentEISOfferCap QueryAllCurrentURDResourceLocked QueryAllSelfDispatchMinViolation QueryAllSelfDispatchMaxViolation

Query Type: no parameters This query type does not accept any query parameters. You query for the most current data.

QueryViolationRelaxationLimit Query Type: by date, and optionally by interval ending, VRL type, and entity (constraint and/or resource) type and name. If no VRL type is specified then all types will be returned. If no entity type is specified then VRLs applying to both constraints and resources will be returned.


75

7.1 Query Overview The participant can query for any data that is published by the SPP market system. This includes some public data (market schedule, load forecast, energy LMP) and it includes private data such as market results, private operator messages, or participant submitted data. Private data can only be queried by the MP that submitted the data or the MP that owns the resources associated with the data.

A data query is specified using the <QueryRequest> element. You may specify only a single request for each instance of <QueryRequest> message. To submit multiple requests, you must submit multiple messages, each describing the <QueryRequest> element.

Data queries can be submitted as a file upload. This is accomplished by formulating the XML query message in an text XML file and posting it to be uploaded using the SPP Upload/Download web page on the SPP Portal. The response message of the file upload query is a file download where the user is allowed to choose a local computer location to place the downloaded result file.

Subsequent sections in this chapter describe the query semantics with respect to the type of query message based on the parameters that are specified to support the query selection. For example, all query requests requiring the date and hour (optional) are formulated in the same way. Actual message formats of each type of message queried are documented in chapter 9.

7.1.1 Query Request and Reply Semantics A query request message follows the request/reply semantics described in chapter 3 of this document. The request message specifies the data set to be queried along with one or more selection parameters to support the query. The response message is the data requested. If the request was not formulated correctly or if an error is encountered then an error response is returned.

All query request message types follow the naming convention shown below.

Query<dataset>

Where <dataset> is the name of the data set being queried. The dataset name is the name of one of the data message sets that are described in chapter 9. For example, to query the EnergyLMP data set, the query element is:


76

QueryEnergyLMP

Or, to query the private data ASCapacityPlan, the query element is:

QueryASCapacityPlan

Remember that all element names are case sensitive and must be spelled with the correct association of upper case and lower case letters.

The successful response to a query is single instance of the <QueryResponse> element. This single <QueryResponse> element may contain zero or more instances of the data set requested. If zero instances are returned then that means that there is no matching data per the request parameters.

The following example shows a query request for a participant’s submitted Resource Plan: <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryResourcePlan resource="GEN1" type="GEN" day="2004-04-01"/> </QueryRequest> </env:Body> </env:Envelope>

The successful response to the above query would appear as shown in the example below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <ResourcePlan resource="GEN1" type="GEN" day="2004-04-01"> …data… </ResourcePlan> </QueryResponse> </env:Body> </env:Envelope>

In this example, there is only one instance of the <ResourcePlan> that satisfies the query but in other kinds of queries there may be multiple instances of data elements so they are contained within a single instance of <QueryResponse>.

For example, the following shows the query for operator messages: <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryOperatorMessage/>


77

</QueryRequest> </env:Body> </env:Envelope>

The successful response would return all messages that are currently active for the participant. This may be more than one message that had been issued at any time in the past. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <OperatorMessage> …data </OperatorMessage> <OperatorMessage> …data </OperatorMessage> <OperatorMessage> …data </OperatorMessage> </QueryResponse> </env:Body> </env:Envelope>

If the query request does not return data because no data exists that satisfies the query request, the response element is returned empty. Note that this is not considered an error. It is not an error to query for something that does not exist. If you specified a query and the parameter was in error then you would receive an error but not when the parameters specify a correct query request.

In the following example, the query is for obligations. In this case, the query is for a particular day and hour but for this example it is assumed that no obligations exist for that day and hour. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryASCapacityObligation day="2004-12-25"> <Hour>12</Hour> </QueryASCapacityObligation> </QueryRequest> </env:Body> </env:Envelope>

Given that no data exists that satisfy the above query, the response appears as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"/> </env:Body> </env:Envelope>


78

If an error exists then the error result message is returned as part of the query result contained in the <QueryResponse> element.

For example, in the above query request scenario, let's assume that the resource identified as GT-1 does not exist. Then an error is returned as shown in the following example. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <Error> <Text>Resource GEN1 does not exist</Text> </Error> </QueryResponse> </env:Body> </env:Envelope>

Errors will never be returned mixed with data. A single data set request either results in success with data returned or it results in an error and data is not returned.

7.2 Query ASCapacityObligation

7.2.1 Query Description This query is used to obtain the MP's ancillary service capacity obligation notices. These obligation notices are sent by notification message to MP's on the day ahead of the operating day. This query can be executed any time to obtain these obligation notification messages.

The query request accepts two parameters. The operating day is a required parameter of the request. This specifies the operating date of the obligation. It does not specify the date that notifications were sent but rather the date of the obligation itself. The second parameter is optional and specifies a given hour. If this optional argument is not given then all hours of the day are returned in response to the request.

7.2.2 Query Schema Template <QueryASCapacityObligation day="yyyy-mm-dd"> <Hour [isDuplicateHour="true"]>hh</Hour> </QueryASCapacityObligation>

7.2.3 Query Data Description Element or Attribute Data Type Description

<QueryASCapacity Obligation>

Complex Type Specifies query request for


79

Element or Attribute Data Type Description the given operating day and optionally the specified hour.

day Date Specifies the operating day of the obligations. This is a required parameter.

<Hour> Hour Ending Specifies the desired hour of the obligation. Optional, if not specified then all hours of the operating day are returned.

isDuplicateHour Boolean Specifies that the hour given above is the duplicate hour during the fall Daylight Saving Time transition to standard time. This attribute is optional and if not specified the default value is false which specifies that the hour is not a duplicate hour.

7.2.4 Availability The query can be executed by the MP that normally would be receiving the ancillary service obligation messages by notification. Only those obligation messages for the named MP can be retrieved. These messages are normally made available by 7 AM on the day ahead of the operating day21.

7.2.5 Query Results The result of the query is zero or more instances of the ASCapacityObligation element. This element is identical to the element used in the Notification message and is documented in chapter 9 of this specification.

7.2.6 Query Examples

7.3 Query ASCapacityPlan This query is used to obtain the MP's submitted ancillary service capacity plan. Only the submitter of a capacity plan can retrieve it using this query.



80

Although the capacity plan can be submitted in bulk, covering multiple days, the query is limited to a single day. Multiple days of data require separate queries.

Also, the query request supports parameters that limit the query based on the hour of the plan schedule, the ancillary service product code involved, or the control area of the obligation or resource. These parameters can be used singly or in concert with each other to further filter the query request scope.

7.3.1 Query Description

7.3.2 Query Schema Template <QueryASCapacityPlan day="yyyy-mm-dd"> <Hour [isDuplicateHour="true"]>hh</Hour> <ASProductCode>sss</ASProductCode> <ControlArea>sss</ControlArea> </QueryASCapacityPlan>


<QueryASCapacityPlan> Complex Type Specifies the query request. This element specifies a query for the capacity plan of a given operating day.

day Date Specifies the operating date of the capacity plan data being requested. This is a required parameter.

<Hour> Hour Ending Specifies the hour of the plan desired. All obligations and resource schedules specified for the given hour will be returned. This is optional. If not specified then all hours of the specified date are returned.

isDuplicateHour Boolean Specifies that the hour given above is the duplicate hour during the fall Daylight Saving Time transition to standard time. This attribute is optional and is only required if a duplicate hour is being specified. The default value of false


81

Element or Attribute Data Type Description specifies that the hour is not a duplicate hour.

<ASProductCode> (URS,DRS,SPIN,SUPP) Specifies the ancillary service product code for the obligation. URS – up regulation service DRS – down regulation service SPIN – spinning reserve service SUPP – supplemental reserve service

<ControlArea> Control Area Name Specifies the control area name. Optional. If specified, only the ancillary service capacity plans in the given control area are returned.

7.3.4 Availability This query may be executed at any time by the MP who submitted the data being queried.

7.3.5 Query Results The result of this query is a single instance of the ASCapacityPlan element that is defined in chapter 9 of this specification. If there are no ancillary service capacity plan schedules that correspond to the query parameters then this element will be empty.

Note: Because of the filtering parameters that can be specified on the query request, the query results may represent data that is not in balance – that is, the balance of MW for obligations and resources of a given hour. Therefore, if the query is used to obtain data for submitting again to the RTO, care must be exercised to ensure that the submitted data is balanced.

7.3.6 Query Examples The following example shows the query request for an ancillary service capacity plan submitted by the MP. This first example shows the query for a given operating day without any other request parameters being specified. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryASCapacityPlan day="2004-03-01"/> </QueryRequest> </env:Body> </env:Envelope>

The results of this query appear is shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">


82

<env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <ASCapacityPlan day="2004-03-01"> …data… </ASCapacityPlan> </QueryResponse> </env:Body> </env:Envelope>

Note that in the above query response only a single element instance of ASCapacityPlan is returned since this describes a given operating date.

In the next example, the query request specifies an hour and control area. The ASProductCode element is not used in this next example so it is left out. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryASCapacityPlan day="2004-03-01"> <Hour>13</Hour> <ControlArea>CA1</ControlArea> </QueryASCapacityPlan> </QueryRequest> </env:Body> </env:Envelope>

The resultant data appears much like as shown in the first example above except that the details of the data will be filtered by the given hour and control area name. This result will not be duplicated here.

In the next example, all three parameters are specified. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryASCapacityPlan day="2004-03-01"> <Hour>13</Hour> <ASProductCode>SUPP</ASProductCode> <ControlArea>CA1</ControlArea> </QueryASCapacityPlan> </QueryRequest> </env:Body> </env:Envelope>

In this example, only the schedules involving SUPP are returned.

7.4 Query CalculatedCurtailmentLevel

7.4.1 Query Description A new notification will be provided to Market Participants with the Calculated Curtailment Level each time an RTB study is

Formatted: Body Text


83

approved. This query will result in the same data in the notification message.

7.4.2 Query Schema Template <QueryCalculatedCurtailmentLevel resource="sss" type="ttt" day="yyyy-mm-dd"> <Hour [isDuplicateHour="true"]>hh</Hour> </ QueryCalculatedCurtailmentLevel>


<QueryCalculatedCurtailmentLevel>

Complex Type Specifies the query request. This element specifies a query for the getting Calculated Curtailment Level for given resource and operating day.

resource Resource Identity Specifies the resource identifier. This is an optional attribute.

type

Resource Type (PLT, GEN, CLD, XGEN)

Specifies the resource type: PLT – plant GEN – generation unit CLD – controllable load XGEN – generation unit external to the SPP footprint. This is an optional attribute

day

Date Specifies the operating date of the CalculatedCurtailmentValue message being requested.

<Hour> HourElementType Specifies the hour ending of the offer desired. This is optional. If not specified then all hours of the day where a submitted offer exists will be returned.




84

7.4.4 Availability This data is available at the completion of each 5 miniute real-time solution and for a limited historical retention period.

7.4.5 Query Results The query results are one or more instances of the CalculatedCurtailmentLevel element which is described in the message catalog.

7.4.6 Query Examples The following query shows how Calculated Curtailment Level for a given day and a resource is queried. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryCalculatedCurtailmentLevel resource="PLT1" type="PLT" day="2004-01-01"/> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <CalculatedCurtailmentLevel day="yyyy-mm-dd" interval="115"> <Resource>PLT1</Resource> <ResourceType>PLT</ResourceType> <CurtailmentLevel>89<CurtailmentLevel/>

<LastUpdatedTime>2005-05-05T01:00:00.000- 06:00</LastUpdatedTime >

</CalculatedCurtailmentLevel> … </QueryResponse> </env:Body> </env:Envelope>

7.47.5 Query Current EISOffer Cap

7.4.17.5.1 Query Description This query is used to obtain the current state of EISOffer Caps that exist for a given resource.


Formatted: Body Text, Indent: Left: 36 pt

Formatted: Indent: Left: 144 pt

Formatted: Body Text, Indent: Left: 36 pt


85

The only parameter to this query is the resource name. No time parameters are used as the results are meant to reflect the state of EISOffer caps in real time.

7.4.27.5.2 Query Schema Template <QueryCurrentEISOfferCap resource="sss" type="ttt"> </QueryCurrentEISOfferCap>

7.4.37.5.3 Query Data Description Element or Attribute Data Type Description

<QueryCurrentEISOfferCap>

Complex Type Specifies the query request. This element specifies a query for the EISOffer Cap data for a given resource.

resource Resource Identity Specifies the resource identifier.

type Resource Type (PLT, GEN, CLD, XGEN)

Specifies the resource type: PLT – plant GEN – generation unit CLD – controllable load XGEN – generation unit external to the SPP footprint

7.4.47.5.4 Availability This data is available at any time for any resource that the MP owns. No historical data of EISOfferCaps is returned, only the current state is available through this query.

7.4.57.5.5 Query Results The query result is zero or more instances of the CurrentEISOfferCap element that satisfy the query parameters. The CurrentEISOfferCap element is defined in the Message Catalog chapter of this specification.

7.4.67.5.6 Query Examples The following query shows how all Current EISOffer Caps that exist for a given resource are queried. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryCurrentEISOfferCap resource="PLT1" type="PLT"/> </QueryRequest>


86

</env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <CurrentEISOfferCap enabled="true" resource="PLT1" resourceType="PLT"> <Flowgate>FG1</Flowgate> <Flowgate>FG2</Flowgate> <OfferCap>10.00</OfferCap> <EnabledTime>2004-01-01T11:01:00.000-06:00</EnabledTime> </CurrentEISOfferCap> </QueryResponse> </env:Body> </env:Envelope>

Note that an EISOffer Cap may be imposed by multiple flowgate constraints, so multiple instances of the Flowgate element may appear. Also note that the EnabledTime and DisabledTime elements are mutually exclusive. Only one will appear at a time to reflect the time at which the Cap’s status was most recently changed.

7.57.6 Query All Current EISOffer Cap

7.5.17.6.1 Query Description This query is identical the Current EISOffer Cap query except that it allows data to be queried for all pivotal resources for a given market participant.

7.5.27.6.2 Query Schema Template <QueryAllCurrentEISOfferCap> </QueryAllCurrentEISOfferCap>


<QueryAllCurrentEISOfferCap>

Complex Type Specifies the query request. This element specifies a query for the EISOffer Cap data for all resources.

7.5.47.6.4 Query Results The query result is zero or more instances of the CurrentEISOfferCap element that satisfy the query parameters.


87

The CurrentEISOfferCap element is defined in the Message Catalog chapter of this specification.

7.5.57.6.5 Query Examples The following query shows how all Current EISOffer Caps that exist for a given resource are queried. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryAllCurrentEISOfferCap/> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <CurrentEISOfferCap enabled="true" resource="PLT1" resourceType="PLT"> <Flowgate>FG1</Flowgate> <Flowgate>FG2</Flowgate> <OfferCap>10.00</OfferCap> <EnabledTime>2004-01-01T11:01:00.000-06:00</EnabledTime> </CurrentEISOfferCap> </QueryResponse> </env:Body> </env:Envelope>

Note that an EISOffer Cap may be imposed by multiple flowgate constraints, so multiple instances of the Flowgate element may appear. Also note that the EnabledTime and DisabledTime elements are mutually exclusive. Only one will appear at a time to reflect the time at which the Cap’s status was most recently changed.

7.67.7 Query Current URD Resource Locked

7.6.17.7.1 Query Description This query is executed to obtain the current state of URD resource lockouts on a given resource. The message conveys information about whether the resource is locked, when the lockout will end, and the current number of consecutive URD violation intervals.

7.6.27.7.2 Query Schema Template


88

<QueryCurrentURDResourceLocked resource="GEN1" type="GEN"> </QueryCurrentURDResourceLocked>


<QueryCurrentURDResourceLocked>

Complex Type Specifies the query request. This element specifies a query for the current URD resource locked data for a given resource




7.6.47.7.4 Availability Current URD Resource Locked data is available at any time. The data reflects the current state of the system only – no historical data is available through this query.

7.6.57.7.5 Query Results The results of the query are zero or more instances of the <CurrentURDResourceLocked> element that is described in the Message Catalog chapter of this specification.

7.6.67.7.6 Query Examples The following query shows how to request current URD resource lockout data. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryCurrentURDResourceLocked resource="GEN1" type="GEN"/> </QueryRequest> </env:Body>


89

</env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <CurrentURDResourceLocked resource="GEN1" type="GEN"> <Locked>true</Locked> <LockBeginsDay>2004-03-06</LockBeginsDay> <LockBeginsInterval>15</LockBeginsInterval> <LockExpiresDay>2004-03-07</LockExpiresDay> <LockExpiresInterval>15</LockExpiresInterval> <URDViolations>8</URDViolations> </CurrentURDResourceLocked> </QueryResponse> </env:Body> </env:Envelope>

7.77.8 Query All Current URD Resource Locked

7.7.17.8.1 Query Description This query is identical to the Current URD Resource Locked message except that no resource parameter is used, so the data returned is for all resources.

7.7.27.8.2 Query Schema Template <QueryAllCurrentURDResourceLocked> </QueryAllCurrentURDResourceLocked>


<QueryAllCurrentURDResourceLocked>

Complex Type Specifies the query request. This element specifies a query for the current URD resource locked data for all resources

7.7.47.8.4 Query Results The results of the query are zero or more instances of the <CurrentURDResourceLocked> element that is described in the Message Catalog chapter of this specification.


90

7.7.57.8.5 Query Examples The following query shows how to request current URD resource lockout data for all resources owned by the querying participant. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryAllCurrentURDResourceLocked/> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <CurrentURDResourceLocked resource="GEN1" type="GEN"> <Locked>true</Locked> <LockBeginsDay>2004-03-06</LockBeginsDay> <LockBeginsInterval>15</LockBeginsInterval> <LockExpiresDay>2004-03-07</LockExpiresDay> <LockExpiresInterval>15</LockExpiresInterval> <URDViolations>8</URDViolations> </CurrentURDResourceLocked> </QueryResponse> </env:Body> </env:Envelope>

7.87.9 Query DeliverabilityAnalysis

7.8.17.9.1 Query Description This query is used to obtain the results of deliverability analysis calculations for a given day, hour and constraint or by the event ID of a particular execution of the analysis. The analysis is executed manually by a market operator and the data is available immediately after it is complete.

The request parameters included with the query are the operating day and optionally the hour ending, constraint name and/or the event ID of the execution. If the hour ending is not included then results for all hours of the day are included in the response. If the constraint is not specified, then results for all constraints will be included. If the event ID is not included results will be returned for all calculations for the specified day and hour. The event ID parameter can be combined with the constraint and/or hour parameter to filter results from a single execution of the analysis.


91

7.8.27.9.2 Query Schema Template <QueryDeliverabilityAnalysis day="yyyy-mm-dd"> <Hour [isDuplicateHour="true"]>hh</Hour> <Constraint>sss</Constraint> <EventID>999</EventID> </QueryDeliverabilityAnalysis>


<QueryDeliverabilityAnalysis>

Complex Type Specifies the query request. This element specifies a query for the deliverability analysis results for a given day.

day Date Specifies the operating date of the analysis data being requested.

<Hour> Hour Ending Specifies the hour ending of the Constraint’s status assessment. If not specified then all hours of the day where a constraint exists will be returned.

isDuplicateHour Boolean Specifies that the hour given above is the duplicate hour during the fall Daylight Saving Time transition to standard time. This attribute is optional and is only required if a duplicate hour is being specified. The default value of false specifies that the hour is not a duplicate hour.

<Constraint> Constraint Identity Specifies the name of the constraint for which results are requested. This is optional and if not specified results for all constraints are returned.

<EventID> Event ID Specifies the event ID corresponding to an execution of deliverability analysis. This value is supplied in the notification messages for each execution.


92

7.8.47.9.4 Availability This data is made available immediately upon completion of an execution of deliverability analysis calculations (SFTDA). SFTDA is a manual process so data is not made available on an automated schedule. Operators are expected to complete the Day Ahead process by 1700. SFTDA is either a one or two stage process and data will not be available until the final stage is complete. Subsequent SFTDA processes may be executed at any time for a given constraint and time period, so additional data may be available at any time. If no constraints are found to be binding or violated, no data will be available for that SFTDA process. Historical retention is limited and previous day results should not be assumed to exist.

7.8.57.9.5 Query Results The query result is the same as the notification message described under notifications. This is zero or more instances of the DeliverabilityAnalysis element that satisfy the query parameters. The DeliverabilityAnalysis element is defined in chapter 9 of this specification.

7.8.67.9.6 Query Examples The following query shows how all deliverability analysis results that exist for a given date are queried. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryDeliverabilityAnalysis day="2006-01-01"/> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <DeliverabilityAnalysis eventID="12345" day="2006-01-01"> <DeliverabilityAnalysisHourly hour="1"> <Constraint name="FLOWGATEXX" type="Flowgate"> <ConstraintStatus>BF</ConstraintStatus> <EnergyImbalanceMW>-200</EnergyImbalanceMW> <ViolationMW>0</ViolationMW> </Constraint> <Constraint name="FLOWGATEXA" type="Flowgate"> <ConstraintStatus>VF</ConstraintStatus> <EnergyImbalanceMW>-200</EnergyImbalanceMW> <ViolationMW>100</ViolationMW>


93

</Constraint> <Constraint name="FLOWGATEXY" type="Flowgate"> <ConstraintStatus>BE</ConstraintStatus> <EnergyImbalanceMW>200</EnergyImbalanceMW> <ViolationMW>0</ViolationMW> </Constraint> <Constraint name="FLOWGATEXB" type="Flowgate"> <ConstraintStatus>VI</ConstraintStatus> <EnergyImbalanceMW>-200</EnergyImbalanceMW> <ViolationMW>100</ViolationMW> <MPPositiveMW>200</MPPositiveMW> <TotalPositiveMW>400</TotalPositiveMW> <MPReliefMW>50</MPReliefMW> </Constraint> </DeliverabilityAnalysisHourly> <DeliverabilityAnalysisHourly hour="2"> <Constraint name="FLOWGATEXX" type="Flowgate"> <ConstraintStatus>BF</ConstraintStatus> <EnergyImbalanceMW>-200</EnergyImbalanceMW> <ViolationMW>0</ViolationMW> </Constraint> <Constraint name="FLOWGATEXA" type="Flowgate"> <ConstraintStatus>VF</ConstraintStatus> <EnergyImbalanceMW>-200</EnergyImbalanceMW> <ViolationMW>100</ViolationMW> </Constraint> <Constraint name="FLOWGATEXY" type="Flowgate"> <ConstraintStatus>BE</ConstraintStatus> <EnergyImbalanceMW>200</EnergyImbalanceMW> <ViolationMW>0</ViolationMW> </Constraint> <Constraint name="FLOWGATEXB" type="Flowgate"> <ConstraintStatus>VI</ConstraintStatus> <EnergyImbalanceMW>-200</EnergyImbalanceMW> <ViolationMW>100</ViolationMW> <MPPositiveMW>200</MPPositiveMW> <TotalPositiveMW>400</TotalPositiveMW> <MPReliefMW>50</MPReliefMW> </Constraint> </DeliverabilityAnalysisHourly> </DeliverabilityAnalysis> <DeliverabilityAnalysis eventID="12346" day="2006-01-01"> <DeliverabilityAnalysisHourly hour="1"> <Constraint name="FLOWGATEXX" type="Flowgate"> <ConstraintStatus>BF</ConstraintStatus> <EnergyImbalanceMW>-200</EnergyImbalanceMW> <ViolationMW>0</ViolationMW> </Constraint> <Constraint name="FLOWGATEXA" type="Flowgate"> <ConstraintStatus>VF</ConstraintStatus> <EnergyImbalanceMW>-200</EnergyImbalanceMW> <ViolationMW>100</ViolationMW> </Constraint> <Constraint name="FLOWGATEXY" type="Flowgate"> <ConstraintStatus>BE</ConstraintStatus> <EnergyImbalanceMW>200</EnergyImbalanceMW> <ViolationMW>0</ViolationMW> </Constraint> <Constraint name="FLOWGATEXB" type="Flowgate"> <ConstraintStatus>VI</ConstraintStatus> <EnergyImbalanceMW>-200</EnergyImbalanceMW> <ViolationMW>100</ViolationMW> <MPPositiveMW>200</MPPositiveMW>


94

<TotalPositiveMW>400</TotalPositiveMW> <MPReliefMW>50</MPReliefMW> </Constraint> </DeliverabilityAnalysisHourly> <DeliverabilityAnalysisHourly hour="2"> <Constraint name="FLOWGATEXX" type="Flowgate"> <ConstraintStatus>BF</ConstraintStatus> <EnergyImbalanceMW>-200</EnergyImbalanceMW> <ViolationMW>0</ViolationMW> </Constraint> <Constraint name="FLOWGATEXA" type="Flowgate"> <ConstraintStatus>VF</ConstraintStatus> <EnergyImbalanceMW>-200</EnergyImbalanceMW> <ViolationMW>100</ViolationMW> </Constraint> <Constraint name="FLOWGATEXY" type="Flowgate"> <ConstraintStatus>BE</ConstraintStatus> <EnergyImbalanceMW>200</EnergyImbalanceMW> <ViolationMW>0</ViolationMW> </Constraint> <Constraint name="FLOWGATEXB" type="Flowgate"> <ConstraintStatus>VI</ConstraintStatus> <EnergyImbalanceMW>-200</EnergyImbalanceMW> <ViolationMW>100</ViolationMW> <MPPositiveMW>200</MPPositiveMW> <TotalPositiveMW>400</TotalPositiveMW> <MPReliefMW>50</MPReliefMW> </Constraint> </DeliverabilityAnalysisHourly> </DeliverabilityAnalysis> </QueryResponse> </env:Body> </env:Envelope>

Not all of the hours are shown but a response could contain hours for the entire day. Note that the DeliverabilityAnalysis element is repeated with a different event ID for each distinct execution of the analysis.

The next example shows a query for a single hour. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryDeliverabilityAnalysis day="2006-01-01"> <Hour>1</Hour> </QueryDeliverabilityAnalysis> </QueryRequest> </env:Body> </env:Envelope>

The result of the above query is shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <DeliverabilityAnalysis eventID="12345" day="2006-01-01">


95

<DeliverabilityAnalysisHourly hour="1"> <Constraint name="FLOWGATEXX" type="Flowgate"> <ConstraintStatus>BF</ConstraintStatus> <EnergyImbalanceMW>-200</EnergyImbalanceMW> <ViolationMW>0</ViolationMW> </Constraint> <Constraint name="FLOWGATEXA" type="Flowgate"> <ConstraintStatus>VF</ConstraintStatus> <EnergyImbalanceMW>-200</EnergyImbalanceMW> <ViolationMW>100</ViolationMW> <MPPositiveMW>200</MPPositiveMW> <TotalPositiveMW>400</TotalPositiveMW> <MPReliefMW>50</MPReliefMW> </Constraint> <Constraint name="FLOWGATEXY" type="Flowgate"> <ConstraintStatus>BE</ConstraintStatus> <EnergyImbalanceMW>200</EnergyImbalanceMW> <ViolationMW>100</ViolationMW> </Constraint> <Constraint name="FLOWGATEXB" type="Flowgate"> <ConstraintStatus>VF</ConstraintStatus> <EnergyImbalanceMW>200</EnergyImbalanceMW> <ViolationMW>100</ViolationMW> </Constraint> </DeliverabilityAnalysisHourly> </DeliverabilityAnalysis> <DeliverabilityAnalysis eventID="12346" day="2006-01-01"> <DeliverabilityAnalysisHourly hour="1"> <Constraint name="FLOWGATEXX" type="Flowgate"> <ConstraintStatus>BE</ConstraintStatus> <EnergyImbalanceMW>200</EnergyImbalanceMW> <ViolationMW>00</ViolationMW> </Constraint> <Constraint name="FLOWGATEXA" type="Flowgate"> <ConstraintStatus>VF</ConstraintStatus> <EnergyImbalanceMW>-200</EnergyImbalanceMW> <ViolationMW>100</ViolationMW> </Constraint> <Constraint name="FLOWGATEXY" type="Flowgate"> <ConstraintStatus>BF</ConstraintStatus> <EnergyImbalanceMW>-200</EnergyImbalanceMW> <ViolationMW>100</ViolationMW> </Constraint> <Constraint name="FLOWGATEXB" type="Flowgate"> <ConstraintStatus>VI</ConstraintStatus> <EnergyImbalanceMW>-200</EnergyImbalanceMW> <ViolationMW>100</ViolationMW> <MPPositiveMW>200</MPPositiveMW> <TotalPositiveMW>400</TotalPositiveMW> <MPReliefMW>50</MPReliefMW> </Constraint> </DeliverabilityAnalysisHourly> </DeliverabilityAnalysis> </QueryResponse> </env:Body> </env:Envelope>

The next example shows a query for a single hour and constraint. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml">


96

<QueryDeliverabilityAnalysis day="2006-01-01"> <Hour>1</Hour> <Constraint>FLOWGATEXX</Constraint> </QuerydeliverabilityAnalysis> </QueryRequest> </env:Body> </env:Envelope>

The result of the above query is shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <DeliverabilityAnalysis eventID="12345" day="2006-01-01"> <DeliverabilityAnalysisHourly hour="1"> <Constraint name="FLOWGATEXX" type="Flowgate"> <ConstraintStatus>BF</ConstraintStatus> <EnergyImbalanceMW>-200</EnergyImbalanceMW> <ViolationMW>0</ViolationMW> </Constraint> </DeliverabilityAnalysisHourly> </DeliverabilityAnalysis> <DeliverabilityAnalysis eventID="12346" day="2006-01-01"> <DeliverabilityAnalysisHourly hour="1"> <Constraint name="FLOWGATEXX" type="Flowgate"> <ConstraintStatus>BF</ConstraintStatus> <EnergyImbalanceMW>-200</EnergyImbalanceMW> <ViolationMW>0</ViolationMW> </Constraint> </DeliverabilityAnalysisHourly> </DeliverabilityAnalysis> </QueryResponse> </env:Body> </env:Envelope>

The next example shows a query for a single event ID, hour and constraint. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryDeliverabilityAnalysis day="2006-01-01"> <EventID>12345</EventID> <Hour>1</Hour> <Constraint>FLOWGATEXX</Constraint> </QueryDeliverabilityAnalysis> </QueryRequest> </env:Body> </env:Envelope>

The result of the above query is shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <DeliverabilityAnalysis eventID="12345" day="2006-01-01"> <DeliverabilityAnalysisHourly hour="1">


97

<Constraint name="FLOWGATEXX" type="Flowgate"> <ConstraintStatus>BF</ConstraintStatus> <EnergyImbalanceMW>200</EnergyImbalanceMW> <ViolationMW>100</ViolationMW> </Constraint> </DeliverabilityAnalysisHourly> </DeliverabilityAnalysis> </QueryResponse> </env:Body> </env:Envelope>

7.97.10 Query Dispatch

7.9.17.10.1 Query Description This query is used to obtain the dispatch messages that were sent to the MP issuing the query. Dispatch messages are sent to the MP by notification for each resource that is participating in the real-time energy imbalance service market. Dispatch messages may be queried at any time after they are sent out.

The request parameters included with the query are the resource identity and type, the operating day, and optionally the 5-minute interval of the dispatch instruction and the dispatch type. If the dispatch interval is not included then dispatch instructions for all intervals of the day are included in the response. If the dispatch type is not specified, then dispatches of all types are included in the response.

7.9.27.10.2 Query Schema Template <QueryDispatch resource="sss" type="ttt" day="yyyy-mm-dd"> <Interval [isDuplicateHour="true"]>hhmm</Interval> <DispatchType>sss</DispatchType> </QueryDispatch>


<QueryDispatch> Complex Type Specifies the query request. This element specifies a query for the dispatch messages of a given resource and operating day.



Specifies the resource type: PLT – plant GEN – generation unit


98

Element or Attribute Data Type Description CLD – controllable load XGEN – generation unit external to the SPP footprint

day Date Specifies the operating date of the dispatch message data being requested.

<Interval> Interval Ending Specifies the 5-minute interval ending of the dispatch desired. This is optional. If not specified then all intervals that include dispatch for the day are returned.

<DispatchType> (EIS, OOME) Specifies the dispatch type. This is optional. If not specified then dispatches of all types are returned. EIS – energy imbalance service OOME – out-of-merit energy


7.9.47.10.4 Availability This data is available to the MP that originally received or would have received the dispatch messages by notification. For more detail on who receives dispatch messages, see the Dispatch message type in chapter 9. This data is available for each 5-minute interval as it is produced. Future intervals are of course not available. Historical retention is limited and previous day results should not be assumed to exist.


99

7.9.57.10.5 Query Results The query result is the same as the notification message described under notifications. This is zero or more instances of the Dispatch element that satisfy the query parameters. The Dispatch element is defined in chapter 9 of this specification.

7.9.67.10.6 Query Examples The following query shows how all dispatch messages that exist for a given resource on a given date are queried. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryDispatch resource="PLT1" type="PLT" day="2004-01-01"/> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <Dispatch resource="PLT1" type="PLT" day="2004-01-01"> <Interval>15</Interval> <DispatchType>EIS</DispatchType> <DispatchMW>120</DispatchMW> <ApprovalTime>2004-01-01T00:00:00.000-06:00</ApprovalTime> <LIP>999.99</LIP> </Dispatch> <Dispatch resource="PLT1" type="PLT" day="2004-01-01"> <Interval>30</Interval> <DispatchType>EIS</DispatchType> <DispatchMW>120</DispatchMW> <ApprovalTime>2004-01-01T00:00:00.000-06:00</ApprovalTime> <LIP>999.99</LIP> </Dispatch> <Dispatch resource="PLT1" type="PLT" day="2004-01-01"> <Interval>45</Interval> <DispatchType>EIS</DispatchType> <DispatchMW>120</DispatchMW> <ApprovalTime>2004-01-01T00:00:00.000-06:00</ApprovalTime> <LIP>999.99</LIP> </Dispatch> </QueryResponse> </env:Body> </env:Envelope>

Not all of the dispatch intervals are shown above but note that each instance of <Dispatch> reports for a single interval ending. This element is repeated for each interval where data exists.

The next example shows a query for a single interval.


100

<?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryDispatch resource="PLT1" type="PLT" day="2004-01-01"> <Interval>1515</Interval> </QueryDispatch> </QueryRequest> </env:Body> </env:Envelope>

The result of the above query is shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <Dispatch resource="PLT1" type="PLT" day="2004-01-01"> <Interval>1515</Interval> <DispatchType>EIS</DispatchType> <DispatchMW>152</DispatchMW> <ApprovalTime>2004-01-01T00:00:00.000-06:00</ApprovalTime> <LIP>999.99</LIP> </Dispatch> </QueryResponse> </env:Body> </env:Envelope>

Note that when querying for a single interval, only a single instance of the Dispatch element is returned. If there is no data for that interval (no dispatch exists or it is a future interval) then no data is returned and the QueryResponse element will be empty. It is not considered an error to request data in the future that does not yet exist, the result though would be an empty response set.

7.107.11 Query All Dispatch

7.10.17.11.1 Query Description This query message is used to query Dispatch data for all resources. Its function and resulting data are the same as the Dispatch query, except that no resource query parameter is provided.

7.10.27.11.2 Query Schema Template <QueryAllDispatch day="yyyy-mm-dd"> <Interval [isDuplicateHour="true"]>hhmm</Interval> <DispatchType>sss</DispatchType> </QueryAllDispatch>



101

Element or Attribute Data Type Description <QueryAllDispatch> Complex Type Specifies the query request.

This element specifies a query for the dispatch messages of a given operating day.

day Date Specifies the operating date of the dispatch message data being requested.


<DispatchType> (EIS, OOME) Specifies the dispatch type. This is optional. If not specified then dispatches of all types are returned. EIS – energy imbalance service OOME – out-of-merit energy


7.10.47.11.4 Query Results The query result is the same as Dispatch query. This is zero or more instances of the Dispatch element that satisfy the query parameters. The Dispatch element is defined in the Message Catalog chapter of this specification.

7.10.57.11.5 Query Examples The following query shows how all dispatch messages that exist for any resource on a given date are queried.


102

<?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryAllDispatch day="2004-01-01"/> </QueryRequest> </env:Body> </env:Envelope>

7.117.12 Query EISOffer

7.11.17.12.1 Query Description This query request is executed by the MP to retrieve EISOffer's that have been previously submitted into the real-time energy imbalance service market. Only the MP who submitted an offer can retrieve the offer.

The request parameters include the resource identifier, the resource type, the operating day of the EIS market, and optionally the individual hour of the offer.

7.11.27.12.2 Query Schema Template <QueryEISOffer resource="sss" type="ttt" day="yyyy-mm-dd"> <Hour [isDuplicateHour="true"]>hh</Hour> </QueryEISOffer>


<QueryEISOffer> Complex Type Specifies the query request. This element specifies a query for the EIS Offer messages of a given resource and operating day.




day Date Specifies the operating date of the EIS Dispatch message data being requested.


103

Element or Attribute Data Type Description <Hour> Hour Ending Specifies the hour ending of

the offer desired. This is optional. If not specified then all hours of the day where a submitted offer exists will be returned.


7.11.47.12.4 Availability This query may be executed at any time by the MP to retrieve EIS offers that have been previously submitted. There is limited historical retention for previous operating days. Once data has been removed from the market database, it can no longer be retrieved. Only the MP that submitted an EIS offer may retrieve that offer using this query.

7.11.57.12.5 Query Results The query results are zero or more instances of the EISOffer element which is the same as the element used to submit the offer message. The EISOffer element is described in the Message Catalog.

7.11.67.12.6 Query Examples The following query shows how all submitted EISOffer's that exist for a given resource on a given date are queried. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryEISOffer resource="PLT1" type="PLT" day="2004-01-01"/> </QueryRequest> </env:Body> </env:Envelope>


104

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <EISOffer resource="PLT1" type="PLT" day="2004-01-01"> <EISOfferHourly hour="1"> </EISOfferHourly> <EISOfferHourly hour="2"> </EISOfferHourly> … </EISOffer> </QueryResponse> </env:Body> </env:Envelope>

The next example shows a query for a single hour. In this example, we are querying for the duplicate hour of the fall Daylight Saving Time transition day. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryEISOffer resource="PLT1" type="PLT" day="2004-10-31"> <Hour isDuplicateHour="true">2</Hour> </QueryEISOffer> </QueryRequest> </env:Body> </env:Envelope>

The result of the above query is shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <EISOffer resource="PLT1" type="PLT" day="2004-10-31"> <EISOfferHourly isDuplicateHour="true" hour="2"> …data… </EISOfferHourly> </EISOffer> </QueryResponse> </env:Body> </env:Envelope>

7.127.13 Query All EISOffer

7.12.17.13.1 Query Description This query message is used to query EISOffer data for all resources for a given market participant. Its function and resulting data are the same as the EISOffer query, except that no resource query parameter is provided.


105

7.12.27.13.2 Query Schema Template <QueryAllEISOffer day="yyyy-mm-dd"> <Hour [isDuplicateHour="true"]>hh</Hour> </QueryAllEISOffer>


<QueryAllEISOffer> Complex Type Specifies the query request. This element specifies a query for the EIS Offer messages of a given operating day.


<Hour> Hour Ending Specifies the hour ending of the offer desired. This is optional. If not specified then all hours of the day where a submitted offer exists will be returned.


7.12.47.13.4 Query Results The query results are zero or more instances of the EISOffer element which is the same as the element used to submit the offer message. The EISOffer element is described in the Message Catalog chapter.

7.12.57.13.5 Query Examples The following query shows how all submitted EISOffer's that exist for any resource on a given date are queried.


106

<?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryAllEISOffer day="2004-01-01"/> </QueryRequest> </env:Body> </env:Envelope>

7.137.14 Query EnergyLMP

7.13.17.14.1 Query Description This query is used to obtain the hourly locational marginal prices for energy. This query can be executed at any time to obtain the hours where energy prices have been computed. Future hours can be queried but will return nothing. This is not considered an error.

The query parameters include the operating day date, settlement location and location type. If the hour is not given then all hours of the day that are available are returned. The resource and resource type must be specified. To query for all settlement locations use the QueryAllEnergyLMP message.

LMP data is public and prices will be available for all settlement locations regardless of ownership.

7.13.27.14.2 Query Schema Template <QueryEnergyLMP day="yyyy-mm-dd" settlementLocation="sss" locationType="sss"> <Hour [isDuplicateHour="true"]>hh</Hour> </QueryEnergyLMP>


<QueryEnergyLMP> Complex Type Specifies the query request. This element specifies a query for the energy LMP for a given operating day.

day Date Specifies the operating date of the energy LMP data being requested.

settlementLocation Settlement Location Identity

Specifies the settlement location identifier.

locationType Settlement Location Type

Specifies the settlement location type:


107

Element or Attribute Data Type Description (PLT, GEN, CLD, LD, XGEN, EXT)

PLT – plant GEN – generation unit CLD – controllable load LD – load asset XGEN – generation unit external to the SPP footprint EXT – Aggregate pnode external to the SPP footprint

<Hour> Hour Ending Specifies the hour ending of the energy LMP data desired. This is optional. If not specified then all hours of the day where energy LMP values have been computed are returned.


7.13.47.14.4 Availability This data is available at any time for the dates and hours and locations where LMP values have been computed. This data is available to any registered participant.

7.13.57.14.5 Query Results The result of this query is a single instance of the EnergyLMP element. The EnergyLMP element is described in chapter 9. When no data is found this element will be empty.

7.13.67.14.6 Query Examples This example shows a query for a single resource. This request obtains all hours for the given resource. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">


108

<env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryEnergyLMP day="2004-03-06" settlementLocation="LOCATION1" locationType="GEN"/> </QueryRequest> </env:Body> </env:Envelope>

The result of the above query is shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <EnergyLMP day="2004-03-06"> <EnergyLMPHourly hour="1"> <ELMP> <SettlementLocation>LOCATION1</SettlementLocation> <SettlementLocationType>GEN</SettlementLocationType> <Pnode>PNODE1</Pnode> <LMP>23.40</LMP> </ELMP> </EnergyLMPHourly> <EnergyLMPHourly hour="2"> <ELMP> <SettlementLocation>LOCATION1</SettlementLocation> <SettlementLocationType>GEN</SettlementLocationType> <Pnode>PNODE1</Pnode> <LMP>23.40</LMP> </ELMP> </EnergyLMPHourly> … </EnergyLMP> </QueryResponse> </env:Body> </env:Envelope>

The next example shows a query for a single location and a single hour. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryEnergyLMP day="2004-03-06" settlementLocation="LOCATION1" locationType="GEN"> <Hour>12</Hour> </QueryEnergyLMP> </QueryRequest> </env:Body> </env:Envelope>

The result of the above query is shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <EnergyLMP day="2004-03-06">


109

<EnergyLMPHourly hour="12"> <ELMP> <SettlementLocation>LOCATION1</SettlementLocation> <SettlementLocationType>GEN</SettlementLocationType> <Pnode>PNODE1</Pnode> <LMP>23.40</LMP> </ELMP> </EnergyLMPHourly> </EnergyLMP> </QueryResponse> </env:Body> </env:Envelope>

7.147.15 Query All Energy LMP

7.14.17.15.1 Query Description This query is identical to the Energy LMP query except that it allows data to be queried for all available settlement locations. This data is public, so data will be returned for all settlement locations regardless of ownership.

7.14.27.15.2 Query Schema Template <QueryAllEnergyLMP day="yyyy-mm-dd"> <Hour [isDuplicateHour="true"]>hh</Hour> </QueryAllEnergyLMP>


<QueryAllEnergyLMP> Complex Type Specifies the query request. This element specifies a query for the Energy LMP for all resources.

day Date Specifies the operating date of the Energy LMP message data being requested.

<Hour> Hour Ending Specifies the hour ending of the offer desired. This is optional. If not specified then all hours of the day where a submitted offer exists will be returned.

isDuplicateHour Boolean Specifies that the hour given above is the duplicate hour during the fall Daylight Saving Time transition to standard time. This attribute is optional and is only


110

Element or Attribute Data Type Description required if a duplicate hour is being specified. The default value of false specifies that the hour is not a duplicate hour.

7.14.47.15.4 Query Results The query result is zero or more instances of the EnergyLMP element that satisfy the query parameters. The EnergyLMP element is defined in the Message Catalog chapter of this specification.

7.14.57.15.5 Query Examples The following query shows how all Energy LMP data that exists for a given resource are queried. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryAllEnergyLMP day="2006-01-01"> <Hour>5</Hour> </QueryAllEnergyLMP> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <EnergyLMP day="2006-01-01"> <EnergyLMPHourly hour="5"> <ELMP> <SettlementLocation>LOCATION1</SettlementLocation> <SettlementLocationType>GEN</SettlementLocationType> <Pnode>PNODE1</Pnode> <LMP>23.40</LMP> </ELMP> <ELMP> <SettlementLocation>LOCATION2</SettlementLocation> <SettlementLocationType>GEN</SettlementLocationType> <Pnode>PNODE2</Pnode> <LMP>23.40</LMP> </ELMP> </EnergyLMPHourly> … </EnergyLMP> </QueryResponse> </env:Body>


111

</env:Envelope>

7.157.16 Query InvalidResourcePlan

7.15.17.16.1 Query Description This query is executed to obtain current outstanding invalid resource plan messages. Normally, these messages are sent via notification messages to MPs who have submitted resource plans. Using this query, the MP can obtain any invalid resource plan message that is still outstanding and current. There is no historical retention of these messages. If the status of the resource plan changes, then previously issued messages will be lost unless they indicate a continuing problem.

An invalid resource plan is one that fails the validations performed after the resource plan is stored in the database. Thus, a resource plan that does not conform to the XML schema requirements (e.g., that does not specify a resource) will never be returned by this query, because it would not have passed the schema validation and been stored in the database. An example of an invalid resource plan that would be returned by this query is one whose ResourceStatus indicates that the resource is not available, but whose PlanMW is greater than 0.

7.15.27.16.2 Query Schema Template <QueryInvalidResourcePlan/>


<QueryInvalidResourcePlan>

Singleton Type Specifies the query request. This element specifies the query for all outstanding and current invalid resource plan messages.

7.15.47.16.4 Availability These messages may be queried by the MP that submitted the resource plan. This query can be executed at any time. The validation is performed each day at 11 AM22 so the status of these messages changes once per day.



112

7.15.57.16.5 Query Results The result of this query is zero or more instances of the InvalidResourcePlan message defined in chapter 9.

7.15.67.16.6 Query Examples The following example shows the query request for InvalidResourcePlan messages. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryInvalidResourcePlan/> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <InvalidResourcePlan time="2004-01-01T11:01:00.000-06:00"> …data… </InvalidResourcePlan> <InvalidResourcePlan time="2004-01-01T11:01:00.000-06:00"> …data… </InvalidResourcePlan> <InvalidResourcePlan time="2004-01-01T11:01:00.000-06:00"> …data… </InvalidResourcePlan> </QueryResponse> </env:Body> </env:Envelope>

7.167.17 Query MarketSchedule

7.16.17.17.1 Query Description The query for market schedule is issued to obtain the current schedule of submission gate closures for Resource Plans, AS Capacity Plans and EIS Offers for the next hour to close. Also returned are the schedules for the first and last AS Capacity Plan Mismatch and Invalid Resource Plan notifications for the day- ahead. The query though is always for the current schedule of events.

7.16.27.17.2 Query Schema Template <QueryMarketSchedule/>


113


<QueryMarketSchedule> Singleton Type Specifies the query request. This element specifies the query for the current market schedules.

7.16.47.17.4 Availability The market schedule is public data and can be queried by any participant at any time.

7.16.57.17.5 Query Results The query result is one instance of the MarketSchedule message type defined in chapter 9 in this document. Query Examples

The following example shows the query request for the MarketSchedule. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryMarketSchedule/> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <MarketSchedule> <Market> ..data.. </Market> <Market> ..data.. </Market> </MarketSchedule> </QueryResponse> </env:Body> </env:Envelope>

7.177.18 Query MidtermLoadForecast

7.17.17.18.1 Query Description This query is used to obtain the hourly midterm load forecast. The midterm load forecast is available up to seven days in the future.


114

The query parameters include the desired day (required) and optionally a specific hour or load area. If the hour and load area are not specified then all hours and load areas available for the date are returned in response to the query. If a specific hour is requested than only that hour is returned. If a specific load area is requested then only that load area is returned.

7.17.27.18.2 Query Schema Template <QueryMidtermLoadForecast day="2004-03-06"> <Hour [isDuplicateHour="true"]>hh</Hour> <LoadArea>sss</LoadArea> </QueryMidtermLoadForecast>


<QueryMidtermLoadForecast>

Complex Type Specifies the query request. This element specifies a query for the midterm load forecast for a given operating day.

day Date Specifies the operating date of the load forecast data being requested.

<Hour> Hour Ending Specifies the hour ending of the data desired. This is optional. If not specified then all hours of the day where load forecast values have been computed are returned.


<LoadArea> Load Area Name Specifies the load area name. If not specified, then all load areas are returned.


115

7.17.47.18.4 Availability The midterm load forecast data is available to all registered participants. It is available for the current day and up to seven days in the future. Historical data is available up to the retention period of the market database. Historical retention of load forecast data is limited. The daily midterm load forecast is computed and posted at 7 AM each day23.

7.17.57.18.5 Query Results The result of this query is a single instance of the MidtermLoadForecast element that is described in chapter 9 of this specification. If no data is found this element will be empty.

7.17.67.18.6 Query Examples The following query shows how to request all midterm load forecast data available for a given date. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryMidtermLoadForecast day="2004-03-06"/> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <MidtermLoadForecast day="2004-03-06"> <LoadForecastHourly hour="1"> <Forecast> … </Forecast> <Forecast> … </Forecast> … </LoadForecastHourly> … </MidtermLoadForecast> </QueryResponse> </env:Body> </env:Envelope>



116

The following query shows how to request all midterm load forecast data available for a given date and hour. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryMidtermLoadForecast day="2004-03-06"> <Hour>15</Hour> </QueryMidtermLoadForecast> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <MidtermLoadForecast day="2004-03-06"> <LoadForecastHourly hour="15"> <Forecast> … </Forecast> <Forecast> … </Forecast> … </LoadForecastHourly> </MidtermLoadForecast> </QueryResponse> </env:Body> </env:Envelope>

The following query shows how to request all midterm load forecast data available for a given date and load area. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryMidtermLoadForecast day="2004-03-06"> <LoadArea>LA1</LoadArea> </QueryMidtermLoadForecast> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <MidtermLoadForecast day="2004-03-06"> <LoadForecastHourly hour="1"> <Forecast>


117

… </Forecast> </LoadForecastHourly> … </MidtermLoadForecast> </QueryResponse> </env:Body> </env:Envelope>

Other queries can be constructed for combinations of hour and load area.

7.187.19 Query MismatchASCapacityPlan

7.18.17.19.1 Query Description This query is executed to receive all outstanding submitted capacity plan mismatch messages. Normally, these mismatch messages are sent by notification to each participant who is either the submitter of the plan or a counterparty to a plan. Only outstanding, current, mismatch messages may be queried. If an earlier notification mismatch message was sent but that mismatch had been corrected then it is no longer considered a mismatch and no longer available for query. There is no historical retention of mismatch messages.

The query for mismatch messages does not include any request parameters other than the implied identity of the MP issuing the request. Only those mismatch messages that are outstanding where the requesting MP is identified as either the party or counterparty are returned in response to the query. If there are no current mismatches in the submitted capacity plan then nothing is returned.

7.18.27.19.2 Query Schema Template <QueryMismatchASCapacityPlan/>


<QueryMismatchASCapacityPlan>

Singleton Type Specifies the query request. This element specifies the query for all outstanding and current capacity plan mismatch messages.

7.18.47.19.4 Availability Mismatch messages are made available only to a MP that plays a part of the mismatch (one of the two possible parties). The


118

mismatches are determined immediately at the time the mismatch is entered into the system.

7.18.57.19.5 Query Results The query results of the mismatch is identical to the notification message posting the mismatch messages. This result uses the MismatchASCapacityPlan message defined in chapter 9.

7.18.67.19.6 Query Examples The following example shows the only type of query that can be executed to obtain mismatch messages. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryMismatchASCapacityPlan/> </QueryRequest> </env:Body> </env:Envelope>

The following is typical of the result one my receive from the query. <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <MismatchASCapacityPlan time="2004-12-25T11:01:00.000-06:00"> …data… </MismatchASCapacityPlan> <MismatchASCapacityPlan time="2004-12-25T11:01:01.000-06:00"> …data… </MismatchASCapacityPlan> <MismatchASCapacityPlan time="2004-12-25T11:01:02.000-06:00"> …data… </MismatchASCapacityPlan> </QueryResponse> </env:Body> </env:Envelope>

The MismatchASCapacityPlan element is repeated for each individual mismatch that exists. If there are no mismatches then the QueryResponse element would be empty.

7.197.20 Query OperatorMessage

7.19.17.20.1 Query Description This query is executed to obtain the current operator messages. Messages are defined to be current for a given period of time. You can optionally query messages that were current at a specified date and time.


119

7.19.27.20.2 Query Schema Template <QueryOperatorMessage> <EffectiveTime>yyyy-mm-ddThh:mm:ss</EffectiveTime> </QueryOperatorMessage>


<QueryOperatorMessage> Complex Type Specifies the query request. <EffectiveTime> DateTime Optional element. Used to

specify the effective time to be used in determining the currency of the operator message. If not specified, the current date and time are used.

7.19.47.20.4 Availability This query request can be issued by all participants at any time. Participant's will receive those operator messages determined to be public or private to the requesting participant.

7.19.57.20.5 Query Results The query results are zero or more instances of the OperatorMessage element that is described in chapter 9 of this specification.

7.19.67.20.6 Query Examples The following query shows how to request all current operator messages. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryOperatorMessage/> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <OperatorMessage> …data…


120

</OperatorMessage> <OperatorMessage> …data… </OperatorMessage> <OperatorMessage> …data… </OperatorMessage> … </QueryResponse> </env:Body> </env:Envelope>

The next request example shows how the operator messages that were current at a given time and date can be obtained. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryOperatorMessage> <EffectiveTime>2004-09-30T22:30:00.000-06:00</EffectiveTime> </QueryOperatorMessage> </QueryRequest> </env:Body> </env:Envelope>

The resulting OperatorMessage instances would appear much like the result shown in the previous example.

7.207.21 Query OperatorOverride

7.20.17.21.1 Query Description This query is executed to obtain operator override messages that have been issued on the participant's submitted ASCapacityPlan or ResourcePlan.

7.20.27.21.2 Query Schema Template <QueryOperatorOverride> <Since>yyyy-mm-ddThh:mm:ss</Since> <Hour [isDuplicateHour="true"]>hh</Hour> <PlanType>sss</PlanType> <Day>yyyy-mm-dd</Day> </QueryOperatorOverride>


<QueryOperatorOverride> Complex Type Specifies the query request. <Since> DateTime Optional element. Used to

specify the effective time to be used in determining the


121

Element or Attribute Data Type Description currency of the operator override message. If not specified, the time 00:00:00 of the current date is used.

<Hour> Hour Ending Optional element. Used to specify the desired hour of any override messages. If not specified then all hours are assumed. If the <Day> element is omitted, this element is ignored.

isDuplicateHour Boolean Specifies the duplicate hour in the fall Daylight Saving Time transition date. If not specified, value is false meaning it is not the duplicate hour.

<PlanType> (ASCapacityPlan, ResourcePlan, Both)

Optional element. Specifies the type of plan involved in operator override messages. If not specified, the default is Both plans.

<Day> Date Optional element. Specifies the date of the plan. If not specified, assumes today's date.

7.20.47.21.4 Availability This query request can be issued by participants at any time. Participants will receive those operator override messages reflecting changes on their submitted plans. Note that an operator override operation can occur at anytime so only those changes made at the time of this query can be considered.

7.20.57.21.5 Query Results The query results are zero or more instances of the OperatorOverride element that is described in chapter 9 of this specification.

7.20.67.21.6 Query Examples The following query shows how to request all current operator override messages issued today.


122

<?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryOperatorOverride/> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <OperatorOverride> …data… </OperatorOverride> … </QueryResponse> </env:Body> </env:Envelope>

The next request example shows how the operator override messages describing data changes against the submitted ASCapacityPlan for the given date. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryOperatorOverride> <PlanType>ASCapacityPlan</PlanType> <Day>2004-04-05</Day> </QueryOperatorOverride> </QueryRequest> </env:Body> </env:Envelope>

The resulting OperatorMessage instances would appear much like the result shown in the previous example. Other combinations of the request parameters can be specified to further filter the results.

7.217.22 Query OverUnderCommitment

7.21.17.22.1 Query Description This query is executed to obtain the results of the most recent validation of Participant Load Forecast, Resource Plan and energy schedule data. You can optionally query for data within a specific Control Area and interval.



123

<QueryOverUnderCommitment day="yyyy-mm-dd"> <Interval [isDuplicateHour="true"]>hhmm</Interval> <ControlArea>sss</ControlArea> </QueryOverUnderCommitment>


<QueryOverUnderCommitment>

Complex Type Specifies the query request. This element specifies a query for the over/undercommitment results for a given operating day.




<ControlArea> Control Area Name

Specifies the control area name. If not specified, then results from all control areas are returned.

7.21.47.22.4 Availability This query request can be issued by all participants at any time. Data will be available for a given interval starting at the 1100 automatic validation on the previous operating day, and subsequent automatic or manual validations will update the data leading up to


124

the interval. Participants will only receive data for control areas in which they have at least one load asset.

7.21.57.22.5 Query Results The query results are zero or more instances of the OverUnderCommitment element that is described in chapter 9 of this specification.

7.21.67.22.6 Query Examples The following query shows how to query OverUnderCommitment validation results for a particular day, interval and control area. xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryOverUnderCommitment day="2004-03-06"> <Interval>1105<Interval> <ControlArea>CA1</ControlArea> </QueryOverUnderCommitment> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <OverUnderCommitment day="2004-03-06"> <Interval>1105</Interval> <ControlArea>CA1</ControlArea> <MinEconomicAvailableCapacityMW>

100 </MinEconomicAvailableCapacityMW> <MaxEconomicAvailableCapacityMW>

1000 </MaxEconomicAvailableCapacityMW> <MinEconomicSelfScheduledCapacityMW>

0 </MinEconomicSelfScheduledCapacityMW> <MaxEconomicSelfScheduledCapacityMW>

0 </MaxEconomicSelfScheduledCapacityMW> <MaxEconomicSupplementalCapacityMW>

0 </MaxEconomicSupplementalCapacityMW>

<PlanManualMW>0</PlanManualMW> <ForecastMW>800</ForecastMW> <ScheduledExportMW>0</ScheduledExportMW> <ASUpRequirementMW>250</ASUpRequirementMW> <ASDownRequirementMW>100</ASDownRequirementMW> <ASUpScheduledMW>250</ASUpScheduledMW> <ASDownScheduledMW>100</ASDownScheduledMW> <OverUnderCommitmentMW>-50</OverUnderCommitmentMW> <Reason>


125

Participant has a capacity undercommitment of 50 MW. </Reason> </OverUnderCommitment> </QueryResponse> </env:Body> </env:Envelope>

See the message description for OverUnderCommitment in Chapter 9 for details on interpreting this message and the calculations involved.

7.227.23 Query ParticipantLoadForecast

7.22.17.23.1 Query Description This query is executed to obtain the participant submitted Load Forecast data. You can optionally query for data within a specific Control Area and hour.

7.22.27.23.2 Query Schema Template <QueryParticipantLoadForecast day="yyyy-mm-dd"> <Hour [isDuplicateHour="true"]>hh</Hour> <ControlArea>sss</ControlArea> </QueryParticipantLoadForecast>


<QueryParticipantLoadForecast>

Complex Type Specifies the query request. This element specifies a query for the Participant Load Forecast data for a given operating day.


<Hour> Hour Ending Specifies the hour ending of the data desired. This is optional. If not specified then all hours of the day up to the most recent current shortterm load forecast is returned.

isDuplicateHour Boolean Specifies that the hour given above is the duplicate hour during the fall Daylight Saving Time transition to standard time. This attribute


126

Element or Attribute Data Type Description is optional and is only required if a duplicate hour is being specified. The default value of false specifies that the hour is not a duplicate hour.


Specifies the control area name. If not specified, then results from all control areas are returned.

7.22.47.23.4 Availability This query request can be issued by all participants at any time. Data will be available as soon as it is submitted by the participant. Participants will only receive data for control areas in which they have at least one load asset.

7.22.57.23.5 Query Results The query result is a single instance of the ParticipantLoadForecast element that is described in chapter 9 of this specification. If no data is found then this element will be empty.

7.22.67.23.6 Query Examples The following query shows how to query ParticipantLoadForecast data for a particular day, hour and control area. xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryParticipantLoadForecast day="2004-03-06"> <Hour>1</Hour> <ControlArea>CA1</ControlArea> </QueryParticipantLoadForecast> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <ParticipantLoadForecast day="2004-01-01"> <ParticipantLoadForecastHourly hour="1"> <ParticipantLoadForecastDetail> <ControlArea>CA1</ControlArea> <ForecastMW>150</ForecastMW> </ParticipantLoadForecastDetail>


127

</ParticipantLoadForecastHourly> </ParticipantLoadForecast> </QueryResponse> </env:Body> </env:Envelope>

7.237.24 Query ResourcePlan

7.23.17.24.1 Query Description This query is used to retrieve resource plans that have been submitted by the MP issuing the request. Resource plans are submitted to include the current day and up to seven days in the future24. Typically, a MP may submit resource plans for multiple days and even multiple resources. However, this query limits the request to a single day and a single resource. Multiple days and multiple resources are supported by using separate query requests.

The query specifies the desired resource by resource identifier and resource type. The query also specifies the date of the desired data. Optionally, a single hour's worth of data can be queried by specifying the Hour element. If this Hour element is not specified then all 24 hours of data are returned.

7.23.27.24.2 Query Schema Template <QueryResourcePlan resource="sss" type="ttt" day="yyyy-mm-dd"> <Hour [isDuplicateHour="true"]>hh</Hour> </QueryResourcePlan>


<QueryResourcePlan> Complex Type Specifies the query request. This element specifies a query for a given resource and date.






128

Element or Attribute Data Type Description day Date Specifies the operating day

for the resource plan. <Hour> Hour Ending Specifies the Hour if only a

single hour is requested. Optional value. If not specified then all hours of the day are returned.

isDuplicateHour Boolean Specifies that the hour given above is the duplicate hour during the fall Daylight Saving Time transition to standard time. This attribute is optional and may not appear unless its value is true. The default value of false specifies that the hour is not a duplicate hour.

7.23.47.24.4 Availability The query for resource plans can be issued at any time by the MP that submitted the plan. A query can specify any day that has data retained in the database. This includes up to seven days in the future as well as some retained history. The amount of retained history is variable per the needs of the database administrator at SPP.

7.23.57.24.5 Query Results The result of the query is a single instance of the ResourcePlan message. If no resource plan data is found this element will be empty..

7.23.67.24.6 Query Examples The following query shows how to query the resource plan for a given resource on a given date. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryResourcePlan resource="GEN1" type="GEN" day="2004-01-04"/> </QueryRequest> </env:Body> </env:Envelope>


129

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <ResourcePlan resource="GEN1" type="GEN" day="2004-01-04"> …data… </ResourcePlan> </QueryResponse> </env:Body> </env:Envelope>

The result above would include all hours of the given day. The next example shows how a specific hour can be requested. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryResourcePlan resource="GEN1" type="GEN" day="2004-01-04"> <Hour>5<Hour> <QueryResourcePlan> </QueryRequest> </env:Body> </env:Envelope>

The result would include only the single hour requested as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <ResourcePlan resource="GEN1" type="GEN" day="2004-01-04"> <ResourcePlanHourly hour="5"> …data… </ResourcePlanHourly> </ResourcePlan> </QueryResponse> </env:Body> </env:Envelope>

7.247.25 Query Self Dispatch Max Violation

7.24.17.25.1 Query Description This query is executed to obtain data on Self Dispatch resources that failed to pass validation against Resource Plan and AS Capacity Plan by having an aggregate scheduled MW that is greater than (RP Max Econ MW – ASCP SPIN MW – ASCP SUPP MW – ASCP URS MW). The query is by one or all resources.



130

<QuerySelfDispatchMaxViolation resource="GEN1" type="GEN"> </QuerySelfDispatchMaxViolation>


<QuerySelfDispatchMaxViolation>

Complex Type Specifies the query request. This element specifies a query for Max violations on self dispatch resources


type Internal Resource Type (PLT, GEN, CLD)

Specifies the resource type: PLT – plant GEN – generation unit CLD – controllable load

7.24.47.25.4 Availability Self Dispatch Violation data is available at any time. The data reflects the current state of the system and validations performed in the configured look-ahead window – no historical data is available through this query. The look-ahead validation time is currently 2 hours, but is subject to change25.

7.24.57.25.5 Query Results The results of the query are zero or more instances of the <SelfDispatchMaxViolation> element that is described in the Message Catalog chapter of this specification.

7.24.67.25.6 Query Examples The following query shows how to request the Self Dispatch Max Violations for a given resource <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QuerySelfDispatchMaxViolation resource="GEN1" type="GEN"/> </QueryRequest> </env:Body> </env:Envelope>



131

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <SelfDispatchMaxViolation day="yyyy-mm-dd" interval="115"> <Resource>GEN1</Resource> <ResourceType>GEN</ResourceType> <ScheduleTotalMW>999</ScheduleTotalMW> <MaxEconomicMW>999</MaxEconomicMW> <SPINMW>999</SPINMW> <SUPPMW>999</SUPPMW> <URSMW>999</URSMW> </SelfDispatchMaxViolation> </QueryResponse> </env:Body> </env:Envelope>

7.257.26 Query All Self Dispatch Max Violation

7.25.17.26.1 Query Description This query is identical to the <QuerySelfDispatchMaxViolation> message except that no resource parameter is used, so the data returned is for all resources registered for the market participant.

7.25.27.26.2 Query Schema Template <QueryAllSelfDispatchMaxViolation> </QueryAllSelfDispatchMaxViolation>


<QueryAllSelfDispatchMaxViolation>

Complex Type Specifies the query request. This element specifies a query for self dispatch max violations for all resources

7.25.47.26.4 Query Results The results of the query are zero or more instances of the <SelfDispatchMaxViolation> element that is described in the Message Catalog chapter of this specification.


132

7.25.57.26.5 Query Examples The following query shows how to request Self Dispatch Max Violation data for all resources <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryAllSelfDispatchMaxViolation/> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <SelfDispatchMaxViolation day="yyyy-mm-dd" interval="115"> <Resource>GEN1</Resource> <ResourceType>GEN</ResourceType> <ScheduleTotalMW>999</ScheduleTotalMW> <MaxEconomicMW>999</MaxEconomicMW> <SPINMW>999</SPINMW> <SUPPMW>999</SUPPMW> <URSMW>999</URSMW> </SelfDispatchMaxViolation> </QueryResponse> </env:Body> </env:Envelope>

7.267.27 Query Self Dispatch Min Violation

7.26.17.27.1 Query Description This query is executed to obtain data on Self Dispatch resources that failed to pass validation against Resource Plan and AS Capacity Plan by having an aggregate scheduled MW that is less than (RP Min Econ MW + DRS MW). The query is by one or all resources.

7.26.27.27.2 Query Schema Template <QuerySelfDispatchMinViolation resource="GEN1" type="GEN"> </QuerySelfDispatchMinViolation>


<QuerySelfDispatchMinViolation>

Complex Type Specifies the query request. This element


133

Element or Attribute Data Type Description specifies a query for Min violations on self dispatch resources


type Internal Resource Type (PLT, GEN, CLD)


7.26.47.27.4 Availability Self Dispatch Violation data is available at any time. The data reflects the current state of the system and validations performed in the configured look-ahead window – no historical data is available through this query. The look-ahead validation time is currently 2 hours, but is subject to change26.

7.26.57.27.5 Query Results The results of the query are zero or more instances of the <SelfDispatchMinViolation> element that is described in the Message Catalog chapter of this specification.

7.26.67.27.6 Query Examples The following query shows how to request the Self Dispatch Min Violations for a given resource <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QuerySelfDispatchMinViolation resource="GEN1" type="GEN"/> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body>



134

<QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <SelfDispatchMinViolation day="yyyy-mm-dd" interval="115"> <Resource>GEN1</Resource> <ResourceType>GEN</ResourceType> <ScheduleTotalMW>999</ScheduleTotalMW> <MinEconomicMW>999</MinEconomicMW> <DRSMW>999</DRSMW> </SelfDispatchMinViolation> </QueryResponse> </env:Body> </env:Envelope>

7.277.28 Query All Self Dispatch Min Violation

7.27.17.28.1 Query Description This query is identical to the <QuerySelfDispatchMinViolation> message except that no resource parameter is used, so the data returned is for all resources.

7.27.27.28.2 Query Schema Template <QueryAllSelfDispatchMinViolation> </QueryAllSelfDispatchMinViolation>


<QueryAllSelfDispatchMinViolation>

Complex Type Specifies the query request. This element specifies a query for self dispatch min violations for all resources

7.27.47.28.4 Query Results The results of the query are zero or more instances of the <SelfDispatchMinViolation> element that is described in the Message Catalog chapter of this specification.

7.27.57.28.5 Query Examples The following query shows how to request Self Dispatch Min Violation data for all resources <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryAllSelfDispatchMinViolation/>


135

</QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <SelfDispatchMinViolation day="yyyy-mm-dd" interval="115"> <Resource>GEN1</Resource> <ResourceType>GEN</ResourceType> <ScheduleTotalMW>999</ScheduleTotalMW> <MinEconomicMW>999</MinEconomicMW> <DRSMW>999</DRSMW> </SelfDispatchMinViolation> </QueryResponse> </env:Body> </env:Envelope>

7.287.29 Query ShorttermLoadForecast

7.28.17.29.1 Query Description This query is executed to obtain the short term load forecast. The short term load forecast is available for the current hour and the next hour.

The query parameters include the desired day (required) and optionally a specific hour or load area. If the hour and load area are not specified then all hours and load areas available for the date are returned in response to the query. If a specific hour is requested than only that hour is returned. If a specific load area is requested then only that load area is returned.

7.28.27.29.2 Query Schema Template <QueryShorttermLoadForecast day="2004-03-06"> <Hour [isDuplicateHour="true"]>hh</Hour> <LoadArea>sss</LoadArea> </QueryShorttermLoadForecast>


<QueryShorttermLoad Forecast>

Complex Type Specifies the query request. This element specifies a query for the shortterm load forecast for a given operating day.


136

Element or Attribute Data Type Description day Date Specifies the operating date

of the load forecast data being requested.

<Hour> Hour Ending Specifies the hour ending of the data desired. This is optional. If not specified then all hours of the day up to the most recent current shortterm load forecast is returned.


<LoadArea> Load Area Name Specifies the load area name. If not specified, then all load areas are returned.

7.28.47.29.4 Availability Short term load forecast data is available to all registered participants for the current hour of the day and the next hour. Historical data (previous hours and dates) is available for a limited historical retention period.

7.28.57.29.5 Query Results The result of the query is a single instance of the <ShorttermLoadForecast> element that is described in chapter 9 of this specification. If no data is found this element will be empty.

7.28.67.29.6 Query Examples The following query shows how to request the short term load forecast for the given day up to the current and next hour's forecast. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml">


137

<QueryShorttermLoadForecast day="2004-03-06"/> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <ShorttermLoadForecast day="2004-03-06"> <LoadForecastInterval interval="15"> <Forecast> … </Forecast> <Forecast> … </Forecast> … </LoadForecastInterval> … </ShorttermLoadForecast> </QueryResponse> </env:Body> </env:Envelope>

Other queries using a variety of settings for the hour or load area can be executed in a manner similar to the examples shown for the Midterm Load Forecast.

7.297.30 Query URD Interval

7.29.17.30.1 Query Description This query is executed to obtain the state of URD Violations on a given resource and at a given interval. Note that this query does not return each notification message that was sent, but instead is a snapshot of the state of URD Violations on the specified resource and time. Data is returned regardless of whether a violation occurred.

If for some reason MOS is down or unable to calculate URD for an interval no data will be returned for that interval, and the MP should interpret this as a URD waived scenario. <QueryURDInterval day="2004-03-06" resource="GEN1" type="GEN"> <Interval isDuplicateHour="false">15</Interval> </QueryURDInterval>



138

Element or Attribute Data Type Description <QueryURDInterval> Complex Type Specifies the query

request. This element specifies a query for the URD interval data for a given resource and day




day Date Specifies the operating date of the URD data being requested.

<Interval> Complex Type Specifies the Interval ending. If only a single interval is requested. Optional value. If not specified then all hours of the day are returned.

isDuplicateHour Boolean Specifies that the hour given above is the duplicate hour during the fall Daylight Saving Time transition to standard time. This attribute is optional and is only required if a duplicate hour

7.29.37.30.3 Availability URD Interval is available at any time. The data returned will reflect the state of URD violations on the specified resource for the given point in time.


139

7.29.47.30.4 Query Results The results of the query are zero or more instances of the <URDInterval> element that is described in the Message Catalog chapter of this specification.

7.29.57.30.5 Query Examples The following query shows how to request the URD for a specified Resource for a given Interval. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryURDInterval day="2004-03-06" resource="GEN1" type="GEN"> <Interval isDuplicateHour"false">15</Interval> </QueryURDInterval> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <URDInterval day="2004-03-06" interval="15" isDuplicateHour="false"> <Resource>GEN1</Resource> <ResourceType>GEN</ResourceType> <URDMW>10</URDMW> <DispatchMW>10</DispatchMW> <GenerationMW>10</GenerationMW> <URDUpRegulationMW>10</URDUpRegulationMW> <URDDownRegulationMW>10</URDDownRegulationMW> <URDWaiver>true</URDWaiver> <URDIntervalViolated>true</URDIntervalViolated> <URDReason>Non-Dispatchable ResourceManualResourcePlan</URDReason> <URDViolations>6</URDViolations> </URDInterval> </QueryResponse> </env:Body> </env:Envelope>

7.307.31 Query All URD Interval

7.30.17.31.1 Query Description This query is identical to the URD Interval message, except that no resource parameter is used so the data returned is for all resources.


140

If for some reason MOS is down or unable to calculate URD for an interval no data will be returned for that interval and the MP should interpret this as a URD waived scenario. <QueryAllURDInterval day="2004-03-06" resource="GEN1" type="GEN"> <Interval isDuplicateHour="false">15</Interval> </QueryAllURDInterval>


<QueryAllURDInterval> Complex Type Specifies the query request. This element specifies a query for the URD interval data for all resources on a given day

day Date Specifies the operating date of the URD interval data being requested.

<Interval> Complex Type Specifies the Interval ending. If only a single hour is requested. Optional value. If not specified then all hours of the day are returned.

isDuplicateHour Boolean Specifies that the hour given above is the duplicate hour during the fall Daylight Saving Time transition to standard time. This attribute is optional and is only required if a duplicate hour

7.30.37.31.3 Query Results The results of the query are zero or more instances of the <URDInterval> element that is described in the Message Catalog chapter of this specification.

7.30.47.31.4 Query Examples The following query shows how to request the short term load forecast for the given day up to the current and next hour's forecast. <?xml version="1.0" encoding="UTF-8"?>


141

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryAllURDInterval day="2004-03-06" > <Interval isDuplicateHour"false">15</Interval> </QueryAllURDInterval> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <URDInterval day="2004-03-06" interval="15" isDuplicateHour="false"> <Resource>GEN1</Resource> <ResourceType>GEN</ResourceType> <URDMW>10</URDMW> <DispatchMW>10</DispatchMW> <GenerationMW>10</GenerationMW> <URDUpRegulationMW>10</URDUpRegulationMW> <URDDownRegulationMW>10</URDDownRegulationMW> <URDWaiver>true</URDWaiver> <URDIntervalViolated>true</URDIntervalViolated> <URDReason>Non-Dispatchable ResourceManualResourcePlan</URDReason> <URDViolations>6</URDViolations> </URDInterval> </QueryResponse> </env:Body> </env:Envelope>

7.317.32 Query Violation Relaxation Limit

7.31.17.32.1 Query Description Violation Relaxation Limit (VRL) data is available at any time after the solution of the corresponding real-time balancing (RTB) interval. <QueryViolationRelaxationLimit day="2004-03-06"> <Interval isDuplicateHour="false">15</Interval> <ViolationRelaxationLimitType>OperationalConstraint</ViolationRelaxationLimitType > <Entity> <ConstraintEntity> <ConstraintName>CONSTRAINT1</ConstraintName> <ConstraintType>Flowgate</ConstraintType> </ConstraintEntity> </Entity> </QueryViolationRelaxationLimit>


142


<QueryViolationRelaxationLimit>

Complex Type Specifies the query request. This element specifies a query for all VRLs for a given day.

day Date Specifies the operating date of the data being requested.

<Interval> Complex Type Specifies the Interval ending. Optional value. If not specified then all intervals of the day are returned.

isDuplicateHour Boolean Specifies that the interval given above is in the duplicate hour during the fall Daylight Saving Time transition to standard time. This attribute is optional and is only required if the specified hour is the duplicate hour.

ViolationRelaxationLimitType

Complex Type Specifies the VRL type Can be either one of the following. OperationalConstraint, RampRate, Capacity, LoadGenBalance

Entity Complex Type Entity could either be a ResourceEntity or a ConstraintEntity

ResourceEntity Complex Type Specifies a resource entity ResourceName String Specifies the name of the

resource ResourceType Complex Type Specifies the type of the

resource ConstraintEntity Complex Type Specifies a constraint entity ConstraintName String Specifies the constraint

name ConstraintType Complex Type Specifies the constraint


143

Element or Attribute Data Type Description type Can have FlowGate, Manual, PNode, RTCA, WatchList, ImportCap values

7.31.37.32.3 Query Results The results of the query are zero or more instances of the <ViolationRelaxationLimit> element that is described in the Message Catalog chapter of this specification.

7.31.47.32.4 Query Examples The following query shows how to request the VRL for a particular day, interval, VRL type and VRL-related entity (in this case a constraint). <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryViolationRelaxationLimit day="2004-03-06"> <Interval isDuplicateHour="false">15</Interval> <ViolationRelaxationLimitType>OperationalConstraint</ViolationRelaxationLimitType > <Entity> <ConstraintEntity> <ConstraintName>CONSTRAINT1</ConstraintName> <ConstraintType>Flowgate</ConstraintType> </ConstraintEntity> </Entity> </QueryViolationRelaxationLimit> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <ViolationRelaxationLimit violationRelaxationLimitType="OperationalConstraint" day="2004-03-06" interval="15"> <OperationalConstraintViolationLimit> <ConstraintName>CONSTRAINT1</ConstraintName> <ConstraintType>Flowgate</ConstraintType> <ViolationMW>15</ViolationMW> </OperationalConstraintViolationLimit> </ViolationRelaxationLimit> </QueryResponse>


144

</env:Body> </env:Envelope>

The following query shows another example, this time querying for a resource-related VRL: <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <QueryViolationRelaxationLimit day="2004-03-06"> <Interval isDuplicateHour="false">15</Interval> <ViolationRelaxationLimitType>RampRate</ViolationRelaxationLimitType > <Entity> <ResourceEntity> <ResourceName>CONSTRAINT1</ResourceName> <ResourceType>OC4</ResourceType> </ResourceEntity> </Entity> </QueryViolationRelaxationLimit> </QueryRequest> </env:Body> </env:Envelope>

The results of the query appear as shown below. <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <QueryResponse xmlns="http://emkt.spp.org/2004/emkt/xml"> <ViolationRelaxationLimit violationRelaxationLimitType="RampRate" day="2004-03-06" interval="15"> <RampRateViolationLimit> <ResourceName>RESOURCE1</ResourceName> <ResourceType>GEN</ResourceType> <ViolationMW>15</ViolationMW> </RampRateViolationLimit> </ViolationRelaxationLimit> </QueryResponse> </env:Body> </env:Envelope>


145

8. Transaction Query 8.1 Transactions Overview

Every successful submit is identified by a unique transaction ID that is returned in response to the SubmitRequest as part of the SubmitResponse <Success> element. The transaction governs all data submitted as part of the SubmitRequest. This can be different sets of data depending on how the participant organized the submittal.

The transactions are described by a transaction log retained in the market database. This transaction log includes important descriptive information about the transaction. More information on this log and its usage can be found in Chapter 4 of this document.

In general, with XML, any data submitted may be retrieved by using the Query By Transaction message described below. This query will retrieve the data as submitted and prior to any database insertion.

The Query by Transaction message is submitted to a special URL server address. This address is documented in section 4.2 of this specification.

8.2 Query By Transaction Identifier To query by transaction identifier you must have the TransactionID that was returned by some previous data submittal. You may query for any previous submittal as long as the data is available. Data is historically retained for a given amount of time and query by transaction only operates on data still available in the market database. Once the transaction has been archived, the data is no longer available for query. Once archival of data has taken place, the data may still be available by calling the RTO help desk.

To query by transaction, you submit the following QueryByTransaction message. Note that this message is not enclosed within a <QueryRequest> element and the query is issued to a specific URL defined for this purpose (see section 4.2). <QueryByTransaction> <TransactionID>ddd</TransactionID> </QueryByTransaction>

The message elements are described in the table below:


146

Element Data Type Description <QueryBy

Transaction> Complex Type Specifies that the query request

is a query by transaction. May be specified only once per request.

<TransactionID> Character String Specifies the transaction identifier for the query by transaction. May be repeated as desired.

The response to a successful query by transaction is a message that contains exactly what was submitted by the transaction. This includes the entire message, including the SOAP envelope, body elements, and <SubmitRequest> content. The following message is an example of such a typical response to QueryByTransaction: <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <SubmitRequest xmlns="http://emkt.spp.org/2004/emkt/xml"> <ASCapacityOffer> -- elements of data -- </ASCapacityOffer> … </SubmitRequest> </env:Body> </env:Envelope>

Only successful submittals can be queried. Therefore, you cannot query and obtain data that was never accepted as part of a transaction. Therefore, the only kind of response you can receive via query by transaction is a successful submittal. If data does not exist for the transaction or if the transaction is in error then you may receive an <Error> type message within the SOAP body of the returned response message.


147

9. Message Catalog 9.1 ASCapacityObligation

9.1.1 Description The ASCapacityObligation message is used to convey to the participant their ancillary service capacity obligation for each hour of the operating day specified. The ASCapacityObligation message is participant private data. This data is made available by 7:30 AM on the day ahead of the operating day.

This data is available to the participant using two different methods:

• This message is sent to each registered MP via the notification subsystem.

• This data is available using the query request message.

Summary

• Message data is participant private data.

• Message data is available by 7:30 AM on the day ahead of the operating day of the obligation.

• Message data is available by notification and by query after 7:30 AM on the day ahead.

• Historical message data is available.

• Submittal and update rules do not apply to this message.


9.1.2 Schema Template <ASCapacityObligation day="yyyy-mm-dd"> <ASCapacityObligationHourly hour="hh" [isDuplicateHour="true"]> <Obligation> <ASProductCode>sss</ASProductCode> <ObligationMW>ddd</ObligationMW> <ControlArea>sss</ControlArea> </Obligation> </ASCapacityObligationHourly> </ASCapacityObligation>

9.1.3 Data Description Element or Attribute Data Type Description


148

Element or Attribute Data Type Description <ASCapacity

Obligation> Complex Type Specifies the capacity

obligation for a given operating day.

day Date Specifies the operating day that is effective for the obligation.

<ASCapacityObligationHourly>

Complex Type Specifies the obligation data for the specified hour-ending period. Repeated for each hour of the day, may occur zero to 25 times.

hour Hour Ending Specifies the hour-ending of the day from 01 through 24.


<Obligation> Complex Type Specifies the obligation for a specific product type. This element may be repeated for different control areas and ancillary service product codes.

<ASProductCode> (URS, DRS,SPIN,SUPP)

Specifies the ancillary service product code for the obligation. URS – up regulation service DRS – down regulation service SPIN – spinning reserve service SUPP – supplemental reserve service

<ObligationMW> MW Specifies the service obligation in MW.

<ControlArea> Control Area Specifies the control area


149

Element or Attribute Data Type Description Name name.

9.1.4 Example The following example shows an ancillary service capacity obligation for the given date and hour. The SOAP wrapping XML is not shown in this example nor is the root element which may be different depending on whether this is received as a notification or a query response.

<ASCapacityObligation day="2004-04-01"> <ASCapacityObligationHourly hour="13"> <Obligation> <ASProductCode>SPIN</ASProductCode> <ObligationMW>40</ObligationMW> <ControlArea>CA1</ControlArea> </Obligation> <Obligation> <ASProductCode>URS</ASProductCode> <ObligationMW>10</ObligationMW> <ControlArea>CA1</ControlArea> </Obligation> </ASCapacityObligationHourly> </ASCapacityObligation>

9.2 ASCapacityPlan

9.2.1 Description The ASCapacityPlan message is used by the MP to submit their ancillary service capacity plan. The ancillary service capacity plan is considered private data. The ancillary service capacity plan must be entered by 11 AM on the day ahead of the operating day. For more information on submittal or update, see the Submit chapter in this specification.

The participant may query this data at any time after submittal. The data returned in response to the query is identical to the data submitted by the participant. Only the participant who submits this ancillary service capacity plan may query for that same data. For more information on query, see the Query Request chapter in this specification.

Summary


• Message data is submitted by 11 AM on the day ahead of the operating day.


150

• Submitted data may be updated at any time prior to 45 minutes prior to the start of the operating hour. Updates include deleting a submitted offer or replacing a submitted offer.

• Submitted data is available by query at any time after submittal.


9.2.2 Schema Template <ASCapacityPlan day="yyyy-mm-dd"> <ASCapacityPlanHourly hour="hh" [isDuplicateHour="true"]> <ASService product="ppp" controlArea="sss"> <Schedule> <ASScheduleCode>sss</ASScheduleCode> <MW>999</MW> <Counterparty>sss</Counterparty> <CounterpartyType>ttt</CounterpartyType> </Schedule> </ASService> </ASCapacityPlanHourly> </ASCapacityPlan>

9.2.3 Data Description Element or Attribute Data Type Description

<ASCapacityPlan> Complex Type Specifies the ancillary service capacity plan for the specified operating day.

day Date Specifies the operating day that is effective for the capacity plan.

<ASCapacityPlan Hourly>

Complex Type Specifies the capacity plan data for the specified hour-ending period. Repeated for each hour of the day, may occur zero to 25 times.


isDuplicateHour Boolean Specifies that the hour given above is the duplicate hour during the fall Daylight Saving Time transition to standard time. This attribute is optional and may not appear unless its value is true. The default value of false specifies that the hour is not a duplicate


151

Element or Attribute Data Type Description hour.

<ASService> Complex Type Specifies the ancillary service schedule for the indicated product and control area. Optional. May not occur or may be repeated multiple times as necessary.

product (URS, DRS, SPIN, SUPP)

Specifies the ancillary service product code. URS – up regulation service DRS – down regulation service SPIN – spinning reserve service SUPP – supplemental reserve service

controlArea Control Area Name

Specifies the control area name.

<Schedule> Complex Type Specifies the capacity scheduled type, MW quantity, counterparty, and counterparty type.

<ASScheduleCode> (Obligation, Resource)

Specifies the capacity as an obligation or resource.

<MW> MW Specifies the scheduled capacity in MW.

<Counterparty> Counterparty Identity

Specifies the counterparty or resource identifier. For an obligation from SPP met by a MP’s own resource, the obligation counterparty is SPP and the resource counterparty is the resource. If MP1’s obligation will be met by MP2, then MP1’s resource counterparty is MP2, and MP2’s obligation counterparty is MP1.

<CounterpartyType> Counterparty Type (PLT,GEN,CLD,TC,RTO)

Specifies the counterparty or resource type: PLT – plant GEN – generation unit CLD – controllable load TC – transmission customer (currently defined as market


152

Element or Attribute Data Type Description participant) RTO – the Regional Transmission Organization (SPP)

9.2.4 Example The following example shows an ancillary service capacity plan for the given date and hour. The SOAP wrapping XML is not shown in this example nor is the root element which may be different depending on whether this is received as a notification or a query response. <ASCapacityPlan day="2004-04-01"> <ASCapacityPlanHourly hour="13"> <ASService product="SUPP" controlArea="CA1"> <Schedule> <ASScheduleCode>Obligation</ASScheduleCode> <MW>100</MW> <Counterparty>SPP</Counterparty> <CounterpartyType>RTO</CounterpartyType> </Schedule> </Schedule> <ASScheduleCode>Resource</ASScheduleCode> <MW>40</MW> <Counterparty>GEN1</Counterparty> <CounterpartyType>GEN</CounterpartyType> </Schedule> </Schedule> <ASScheduleCode>Resource</ASScheduleCode> <MW>50</MW> <Counterparty>GEN2</Counterparty> <CounterpartyType>GEN</CounterpartyType> </Schedule> </Schedule> <ASScheduleCode>Resource</ASScheduleCode> <MW>10</MW> <Counterparty>TC1</Counterparty> <CounterpartyType>TC</CounterpartyType> </Schedule> </ASService> </ASCapacityPlanHourly> </ASCapacityPlan>

9.3 CalculatedCurtailmentLevel

9.3.1 Description MOS should issue a notification to Market Participants (MPs), via XML, of the Calculated Curtailment Level immediately following receipt of this information from CAT.


153

The CalculatedCurtailmentLevel message is sent each time an RTB study is approved. The notifications are sent to the resources where there is a CalculatedCurtailment value. Each MP is sending the notifications for resources which they own.

this message will include:

• Resource Name

• Resource Type

• Calculated Curtailment Level

• Last Updated time

• Interval Ending

9.3.2 Schema Template <CalculatedCurtailmentLevel day="yyyy-mm-dd" interval="hhmm" [isDuplicateHour="true"]> <Resource>sss</Resource> <ResourceType>sss</ResourceType> <CurtailmentLevel>ddd<CurtailmentLevel/>

<LastUpdatedTime>yyyy-mm-ddThh:mm:ss.SSS-zz:ZZ </LastUpdatedTime >

</CalculatedCurtailmentLevel>

9.3.3 Data Description

Element or Attribute Data Type Description <CalculatedCurtailmen

tLevel> Complex Type Specifies the query request.

This element specifies a query for the getting Calculated Curtailment Level for given resource and operating day.

<Resource> Resource Identity Specifies the resource identifier.

<ResourceType> Resource Type (PLT, GEN, CLD, XGEN)



154

Element or Attribute Data Type Description XGEN – generation unit external to the SPP footprint

<CurtailmentLevel> CurtailmentLevelType

Specifies the calculated curtailment level.

<LastUpdatedTime> dateTime Last updated time of the record


interval Interval EndingType

Specifies the hour ending of the offer desired. This is optional. If not specified then all hours of the day where a submitted offer exists will be returned.


9.3.4 Example The following example shows a CalculatedCurtailmentLevel message

<CalculatedCurtailmentLevel day="2011-05-05" interval="115"> <Resource>PLT1</Resource> <ResourceType>PLT</ResourceType> <CurtailmentLevel>89<CurtailmentLevel/>

<LastUpdatedTime>2005-05-05T01:00:00.000- 06:00</LastUpdatedTime >

</CalculatedCurtailmentLevel>


155

9.39.4 CurrentEISOfferCap

9.3.19.4.1 Description The CurrentEISOfferCap message is used to convey the current state of any EISOffer Caps that exist to the participant.

The participant may query this data at any time.

Summary


9.3.29.4.2 Schema Template <CurrentEISOfferCap resource="sss" type="ttt" enabled="false"> <Flowgate>sss</Flowgate> [<Flowgate>sss</Flowgate>…] <OfferCap>ddd.dd</OfferCap>

<EnabledTime>yyyy-mm-ddThh:mm:ss.SSS-zz:ZZ</EnabledTime> <DisabledTime>yyyy-mm-ddThh:mm:ss.SSS-zz:ZZ</DisabledTime> </CurrentEISOfferCap>

9.3.39.4.3 Data Description Element or Attribute Data Type Description

<CurrentEISOfferCap> Complex Type Specifies the current state of a EISOffer Cap for the specified resource




enabled Boolean Specifies whether the cap is currently enabled

<EnabledTime> DateTime If the cap is enabled, this field conveys the time at which it was enabled. Otherwise this field will not be present.

<DisabledTime> DateTime If the cap is disabled, this field conveys the time at which it was disabled. Otherwise this field will not be present.

<Flowgate> String Specifies the name of the


156

Element or Attribute Data Type Description flowgate(s) that have constraints imposing the cap. This element may appear multiple times

<OfferCap> Price Specifies the value at which offers on this resource will be capped

9.3.49.4.4 Example The following example shows a CurrentEISOfferCap for the given resource. The SOAP wrapping XML is not shown in this example nor is the root element which may be different depending on whether this is received as a notification or a query response. <CurrentEISOfferCap resource="GEN1" type="GEN" enabled="true"> <Flowgate>FG1</Flowgate> <OfferCap>100.00</OfferCap> <EnabledTime>2005-05-05T01:00:00.000-06:00</EnabledTime> </CurrentEISOfferCap>

9.49.5 CurrentURDResourceLocked

9.4.19.5.1 Description The CurrentURDResourceLocked message conveys the current state of any URD resource lockouts that are in effect for a given resource registered by the querying participant.

Summary

• Message data is private.

• Message data can be queried at any time.

9.4.29.5.2 Schema Template <CurrentURDResourceLocked resource="sss" type="sss">

<Locked>true</Locked> <LockBeginsDay>yyyy-mm-dd</LockBeginsDay> <LockBeginsInterval [isDuplicate="true"]>hhmm</LockBeginsInterval> <LockExpiresDay>yyyy-mm-dd</LockExpiresDay> <LockExpiresInterval [isDuplicate="true"]>hhmm</LockExpiresInterval> <URDViolations>d</URDViolations> </CurrentURDResourceLocked>


<CurrentURDResourceLocked>

Complex Type Specifies the current state of a


157

Element or Attribute Data Type Description URD resource lockout on a given resource

resource Resource Identity

Specifies the resource identifier.



<Locked> Boolean Specifies whether a URD lockout is in effect for this resource

<LockBeginsDay> Date Specifies the market day on which the lockout began. This element is optional and will not appear unless the resource is locked.

<LockBeginsInterval> IntervalEnding Specifies the interval ending on which the lockout began. This element is optional and will not appear unless the resource is locked.


<LockExpiresDay> Date Specifies the market day on which the lockout will expire. This element is optional and will not appear unless the resource is locked.

<LockExpiresInterval> IntervalEnding Specifies the interval ending on which the lockout will expire. This element is optional and will not appear unless the resource is locked.


158

Element or Attribute Data Type Description isDuplicateHour Boolean Specifies that the hour given

above is the duplicate hour during the fall Daylight Saving Time transition to standard time. This attribute is optional and may not appear unless its value is true. The default value of false specifies that the hour is not a duplicate hour.

<URDViolations> Integer Specifies the number of consecutive URD interval violations on this resource

9.4.49.5.4 Example The following example shows the URD lockout message for the current time. The SOAP wrapping XML is not shown in this example nor is the root element.

<CurrentURDResourceLocked resource="GEN1" type="GEN">

<Locked>true</Locked> <LockBeginsDay>2005-01-01</LockBeginsDay> <LockBeginsInterval isDuplicate="false">15</LockBeginsInterval> <LockExpiresDay>2005-01-02</LockExpiresDay> <LockExpiresInterval isDuplicate="false">15</LockExpiresInterval> <URDViolations>7</URDViolations> </CurrentURDResourceLocked>

9.59.6 DeliverabilityAnalysis

9.5.19.6.1 Description The DeliverabilityAnalysis message conveys the results of feasibility calculations analyzing congestion and impacts on system constraints that may lead to TLR events. Each message will convey the results for a given hour, constraint and feasibility status. The statuses are:

• BE (Binding Economic) – The constraint was binding but only because of a more economic solution than the Plan MW.

• BF (Binding Feasible) – The constraint was binding and required redispatch because the Plan would have resulted in a constraint violation. Schedule curtailments may be necessary in real-time.


159

• VF (Violated Feasible) – The constraint was violated using only available resources for redispatch and required redispatch including changes to self-dispatch schedules and curtailment of inter-RTO schedules in order to relieve the violation. Unit commitment is feasible but TLR is highly likely and Manual deployment of Self-Dispatch resources may also be required.

• VI (Violated Infeasible) – The constraint was violated in the initial run and remained violated with all self-dispatch resources available and inter-RTO schedules curtailed. In this case, the Unit Commitment provided by the Market Participants is infeasible and must be altered.

The deliverability analysis calculations are performed in two stages. The first stage assesses impacts based on the simulated dispatch given the Day-ahead Plan and Available Offers. All constraints that are binding or violated from that simulation are assessed for their Energy Imbalance impacts. If no violated constraints are identified in the first stage then the second stage is not required.

The second stage is performed for periods where any constraints were violated in the first stage. In the second stage all resources that were self-dispatched in the first stage are made available to the dispatch engine and all interRTO schedules are excluded from the case. The dispatch simulation is completed and the originally violated constraints are assessed again.

Notifications will be created for all binding or violated constraints. These notifications will be created even if all of the constraints are classified as Binding Economic where no reliability issue is detected. If a constraint is violated in both stages, a relief amount will be assigned to each Market Participant that must be achieved by altering the given resource plan.

Notifications for each constraint status will specify the difference of planned and dispatched MW impacts which is the Energy Imbalance component. Notifications will also include the violation amount calculated during that stage if applicable. Notifications for the Violated Infeasible (VI) status will specify the total positive impact on the constraint, the MP’s positive impact, and the MP’s MW share of the relief should a TLR be issued. These fields will only be present when the status is VI. Each MP will receive these fields for each constraint of this status, even though the MP may have 0 MW responsibility for relief because their net impact is negative.


160

Notifications will be sent when the SPP Engineer’s process is complete and MPs will receive a single transmission containing all of the notifications for that execution of the analysis.

Since multiple studies could be performed for a given time period, each execution is identified with an Event ID that is specified in the notification. This ID can be used to query back data from only that execution on the MUI.

Summary

• Message data is private

• Message data is sent by notification to registered participants.

• Message data may be queried at any time after its issue.

9.5.29.6.2 Schema Template <DeliverabilityAnalysis eventID="999" day="yyyy-mm-dd"> <DeliverabilityAnalysisHourly hour="hh" [isDuplicateHour="true"]> <Constraint name="sss" type="sss"> <ConstraintStatus>sss</ConstraintStatus> <EnergyImbalanceMW>999</EnergyImbalanceMW> <ViolationMW>999</ViolationMW> <MPPositiveMW>999</MPPositiveMW> <TotalPositiveMW>999</TotalPositiveMW> <MPReliefMW>999</MPReliefMW> </Constraint> </DeliverabilityAnalysisHourly> </DeliverabilityAnalysis>


<DeliverabilityAnalysis>

Complex Type Specifies a deliverability analysis message for a given execution of the calculations.

day Date Specifies the date of the time period for which the analysis was performed.

eventID Event ID Specifies the event ID corresponding to this execution of the deliverability analysis calculations. This ID can be used to query the calculations from only a single execution.

<DeliverabilityAnalysisHourly>

Complex Type Specifes message data for a given hour of deliverablility analysis calculations.

hour Hour Ending Specifies the hour-ending of the day


161

Element or Attribute Data Type Description from 01 through 24


<Constraint> Complex Type Specifies calculation results for a given hour, status and constraint.

Name Constraint Identity

Specifies the constraint name.

type Constraint Type Specifies the constraint type. Possible values are: • PNODE • RTCA • Manual • Watchlist • Flowgate • ImportCap

<ConstraintStatus> Constraint Status

Specifies the status of the constraint determined by the analysis. Possible values are: • BE • BF • VF • VI

<EnergyImbalanceMW> DA Energy Imbalance MW

Specifies the difference between planned and dispatched MW impact on the constraint. This will be a positive value for BE status and a negative value for all others.

<ViolationMW> DA Violation MW

Specifies the violation MW amount calculated for the constraint in the initial stage calculation.

<MPPositiveMW> DA Positive MW (Optional) Specifies the MP’s share in the positive impact on the constraint. Only applicable for VI status.


162

Element or Attribute Data Type Description <TotalPositiveMW> DA Positive MW (Optional) Specifies the total positive

impact on the constraint. Only applicable for VI status.

<MPReliefMW> DA Positive MW (Optional) Specifies the MP’s share in the relief requirement if a TLR is issued. Only applicable for VI status.

9.5.49.6.4 Example The following example shows the deliverability analysis message for the given constraint and hour. The SOAP wrapping XML is not shown in this example nor is the root element. Multiple instances of the constraint are shown to illustrate how the statuses from each stage of calculations are both transmitted in the same message.

<DeliverabilityAnalysis eventID="12345" day="2006-01-01"> <DeliverabilityAnalysisHourly hour="1"> <Constraint name="FLOWGATEXX" type="Flowgate"> <ConstraintStatus>BE</ConstraintStatus> <EnergyImbalanceMW>200</EnergyImbalanceMW> <ViolationMW>0</ViolationMW> </Constraint> <Constraint name="FLOWGATEXB" type="Flowgate"> <ConstraintStatus>VI</ConstraintStatus> <EnergyImbalanceMW>-200</EnergyImbalanceMW> <ViolationMW>100</ViolationMW> <MPPositiveMW>200</MPPositiveMW> <TotalPositiveMW>400</TotalPositiveMW> <MPReliefMW>50</MPReliefMW> </Constraint> </DeliverabilityAnalysisHourly> </DeliverabilityAnalysis>

9.69.7 Dispatch

9.6.19.7.1 Description The Dispatch message is used to send energy imbalance service (EIS) and out-of-merit energy (OOME) dispatch instructions to MPs. Dispatch instructions are sent for each 5-minute interval during real-time on the operating day. This message conveys private data.

The dispatch message is sent as part of a Notifications message pushed to named participants. Dispatch may be issued periodically on a 5-minute interval basis and in extreme circumstances be issued multiple times for the same 5-minute interval. If issued more than once for an interval the notification with the latest “approval time” should be used.

Dispatch is also available by query.


163

Summary


• Message data is sent to MPs using Notifications message.


• There is no participant submittal or update of this data.

9.6.29.7.2 Schema Template <Dispatch resource="sss" type="ttt" day="yyyy-mm-dd"> <Interval [isDuplicateHour="true"]>hhmm</Interval> <DispatchType>sss</DispatchType> <DispatchMW>999</DispatchMW> <ApprovalTime>yyyy-mm-ddThh:mm:ss:SSS-zz:ZZ</ApprovalTime> <LIP>999.99</LIP> </Dispatch>


<Dispatch> Complex Type Specifies the Dispatch message for the associated resource on the operating day specified. This represents a single dispatch instruction.




day Date Specifies the operating day of the dispatch.

<Interval> Interval Ending Specifies the five minute interval of the dispatch.

isDuplicateHour Boolean Specifies that the hour given above in the interval value is the duplicate hour during the fall Daylight Saving Time transition to standard time. This attribute is optional and may not appear unless its value is true. The default


164

Element or Attribute Data Type Description value of false specifies that the hour is not a duplicate hour.

<DispatchType> (EIS, OOME) Specifies the dispatch type: EIS – energy imbalance service OOME – out-of-merit energy

<DispatchMW> MW Specifies the target MW level of the resource.

<ApprovalTime> DateTime Specifies the case approval time for the case from which this dispatch instruction was calculated. If the message is an OOME type Dispatch this field will simply be the time at which the market operator issued the Dispatch.

<LIP> ELMPType Specifies the LIP for the dispatched resource if the dispatch type is EIS. OOME Dispatch messages will be sent with a LIP value of 0, as there is no corresponding case approval for an OOME Dispatch.

9.6.49.7.4 Example The following example shows a Dispatch for the given date, interval, and resource. The SOAP wrapping XML is not shown in this example nor is the root element which may be different depending on whether this is received as a notification or a query response. <Dispatch resource="GEN1" type="GEN" day="2004-04-01"> <Interval>1215</Interval> <DispatchType>EIS</DispatchType> <DispatchMW>230</DispatchMW> <ApprovalTime>2004-01-01T00:00:00.000-06:00</ApprovalTime> <LIP>999.99</LIP> </Dispatch> <Dispatch resource=" GEN2" type="GEN" day="2004-04-01"> <Interval>1215</Interval> <DispatchType>EIS</DispatchType> <DispatchMW>20</DispatchMW> <ApprovalTime>2004-01-01T00:00:00.000-06:00</ApprovalTime> <LIP>999.99</LIP> </Dispatch> <Dispatch resource=" GEN3" type="GEN" day="2004-04-01">


165

<Interval>1215</Interval> <DispatchType>EIS</DispatchType> <DispatchMW>100</DispatchMW> <ApprovalTime>2004-01-01T00:00:00.000-06:00</ApprovalTime> <LIP>999.99</LIP> </Dispatch>

9.79.8 EISOffer

9.7.19.8.1 Description The EISOffer message is submitted by the MP. The EIS Offer is submitted as an hourly resource specific offer curve composed of at least two MW-Price points and up to a maximum of ten MW-Price points. The EIS Offer message is MP-private.

The participant may query this data at any time after submittal. The data returned in response to the query is identical to the data submitted by the participant. Only the participant who submits this EISOffer may query for that same data.

Summary


• Message data is submitted between 15:30 up to 7 days ahead of the operating day and 45 minutes before the start of the operating hour27.

• Submitted data may be updated at any time prior to market close. Updates include deleting a submitted offer or replacing a submitted offer.


9.7.29.8.2 Schema Template <EISOffer resource="sss" type="ttt" day="yyyy-mm-dd"> <EISOfferHourly hour="hh" [isDuplicateHour="true"]> <EISOfferCurve> <EISOfferCurvePoint> <MW>ddd</MW> <Price>ddd.dd</Price> </EISOfferCurvePoint> </EISOfferCurve> </EISOfferHourly> </EISOffer>




166

Element or Attribute Data Type Description <EISOffer> Complex Type Specifies the EIS offer for the

specified resourceand operating day.




day Date Specifies the operating day. <EISOfferHourly> Complex Type Specifies the EIS Offer for the

given hour-ending period. This element may be repeated for each hour included in the offer.



<EISOfferCurve> Complex Type Specifies the offer curve as a set of MW-Price points in strictly monotonically increasing order. Only one offer curve for the hour ending period may be specified. A delete action is signified by the absence of this element. See description in Chapter 5 on submitting and deleting.

<EISOfferCurvePoint> Complex Type Specifies a single offer curve point. At least two such


167

Element or Attribute Data Type Description points must be specified and a maximum of 10 may be specified for a given hourly period.

<MW> Nonnegative MW Specifies the offer point MW value. Must be nonnegative (zero or greater).

<Price> Price Specifies the offer point Price value.

9.7.49.8.4 Example The following example shows an EIS Offer for the given operating day. The SOAP wrapping XML is not shown in this example nor is the root element.

<EISOffer resource="GEN1" type="GEN" day="2004-04-01"> <EISOfferHourly hour="12"> <EISOfferCurve> <EISOfferCurvePoint> <MW>0</MW> <Price>0.00</Price> </EISOfferCurvePoint> <EISOfferCurvePoint> <MW>50</MW> <Price>5.00</Price> </EISOfferCurvePoint> <EISOfferCurvePoint> <MW>100</MW> <Price>7.00</Price> </EISOfferCurvePoint> <EISOfferCurvePoint> <MW>200</MW> <Price>12.00</Price> </EISOfferCurvePoint> </EISOfferCurve> </EISOfferHourly> </EISOffer>

9.89.9 EISOfferCap

9.8.19.9.1 Description The EISOfferCap message is used to send offer cap information to MPs. EISOfferCap messages are sent daily to owners of pivotal resources and contain the offer cap for the next day. This message conveys private data.

The offer cap message is sent as part of a Notifications message pushed to named participants. EISOfferCap may be issued on a daily basis. EISOfferCap is also available by query.


168

Summary





9.8.29.9.2 Schema Template <EISOfferCap day="yyyy-mm-dd"> <Resource>sss</Resource> <ResourceType>sss</ResourceType> <OfferCap>ddd.dd</OfferCap> </EISOfferCap>


<EISOfferCap> Complex Type Specifies the EISOfferCap message for the associated resource on the effective time specified. This represents a single offer cap.

day Date Specifies the effective date of the offer cap.


<ResourceType> Resource Type Specifies the resource type: PLT – plant GEN – generation unit CLD – controllable load XGEN – generation unit external to the SPP footprint

<OfferCap> Price Specifies the Offer Cap value.

9.8.49.9.4 Example The following example shows an EISOfferCap. The SOAP wrapping XML is not shown in this example nor is the root element which may be different depending on whether this is received as a notification or a query response. <EISOfferCap day="2005-03-10"> <Resource>GEN1</Resource> <ResourceType>GEN</ResourceType> <OfferCap>250.00</OfferCap> </EISOfferCap>


169

9.99.10 EISOfferCapEnabled

9.9.19.10.1 Description The EISOfferCapEnabled message is used to report that an offer cap has been placed on a resource. EISOfferCapEnabled messages are sent to resource owners when a resource is capped as the result of a flowgate constraint being enabled. An EISOfferCapEnabled may also be sent as a reminder message for resources that remain capped. This message conveys private data.

The offer cap enabled message is sent as part of a Notifications message pushed to named participants. EISOfferCapEnabled is issued when flowgate constraints are enabled. EISOfferCapEnabled reminder messages may be issued hourly. EISOfferCapEnabled is also available by query.

Summary





9.9.29.10.2 Schema Template <EISOfferCapEnabled time="yyyy-mm-ddThh:mm:ss" [reminder=false]> <Resource>sss</Resource> <ResourceType>sss</ResourceType> <OfferCap>ddd.dd</OfferCap> <Flowgate>sss</Flowgate> </EISOfferCapEnabled>


<EISOfferCapEnabled> Complex Type Specifies the EISOfferCapEnabled message for the associated resource.

time DateTime Specifies the time operator enabled the flowgate constraint.

reminder Boolean Specifies the message is a


170

Element or Attribute Data Type Description reminder message. This attribute is optional and may not appear unless its value is “true”.



<OfferCap> Price Specifies the Offer Cap value.<Flowgate> Flowgate Identity Specifies the flowgate

identifier.

9.9.49.10.4 Example The following example shows two EISOfferCapEnabled messages. The first an example of the initial message. The second an example of the reminder message. The SOAP wrapping XML is not shown in this example nor is the root element which may be different depending on whether this is received as a notification or a query response. <EISOfferCapEnabled time="2005-05-01T13:02:01.000-06:00"> <Resource>GEN1</Resource> <ResourceType>GEN</ResourceType> <OfferCap>250.00</OfferCap> <Flowgate>FG1</Flowgate> </EISOfferCapEnabled> <EISOfferCapEnabled time="2005-05-01T13:02:01.000-06:00" reminder="true"> <Resource>GEN2</Resource> <ResourceType>GEN</ResourceType> <OfferCap>250.00</OfferCap> <Flowgate>FG2</Flowgate> </EISOfferCapEnabled>

9.109.11 EISOfferCapDisabled

9.10.19.11.1 Description The EISOfferCapDisabled message is used to report that a flowgate imposed offer cap has been disabled. A resource is capped as the result of a flowgate constraint being enabled.


171

EISOfferCapDisabled messages are sent to owners of capped resources when the flowgate constraint is disabled.

NOTE: It is possible that a resource is pivotal to more than one flowgate. As a result, this receipt of this message only means that the enabling of the cap from the perspective of one flowgate has been revoked. If the resource was capped due to two flowgates, then the resource will remain capped until both flowgate constraints are disabled.

This message conveys private data.

The offer cap disabled message is sent as part of a Notifications message pushed to named participants. EISOfferCapDisabled is issued when flowgate constraints are disabled. EISOfferCapDisabled is also available by query.

Summary


• Message data is sent to MPs using Notifications message.



9.10.29.11.2 Schema Template <EISOfferCapDisabled time="yyyy-mm-ddThh:mm:ss.SSS-zz:ZZ"> <Resource>sss</Resource> <ResourceType>sss</ResourceType> <Flowgate>sss</Flowgate> </EISOfferCapDisabled>


<EISOfferCapDisabled> Complex Type Specifies the EISOfferCapDisabled message for the associated resource.

time DateTime Specifies the time operator disabled the flowgate constraint.


<ResourceType> Resource Type Specifies the resource type: PLT – plant


172

Element or Attribute Data Type Description GEN – generation unit CLD – controllable load XGEN – generation unit external to the SPP footprint

<Flowgate> Flowgate Identity Specifies the flowgate identifier.

9.10.49.11.4 Example The following example shows an EISOfferCapDisabled message. The SOAP wrapping XML is not shown in this example nor is the root element which may be different depending on whether this is received as a notification or a query response. <EISOfferCapDisabled time="2005-05-01T13:02:01.000-06:00"> <Resource>GEN1</Resource> <ResourceType>GEN</ResourceType> <Flowgate>FG1</Flowgate> </EISOfferCapDisabled>

9.119.12 EnergyLMP

9.11.19.12.1 Description The EnergyLMP message reports the market clearing prices for energy. The price is reported as a locational marginal price (LMP, also referred to as the LIP or Locational Imbalance Price) for a given settlement location. Also returned is the location pricing node (pnode) associated with the settlement location. This message is public data, and prices will be available for all settlement locations regardless of ownership.

The participant may query this data at any time after market clearing and results have been published by the RTO.

Summary

• Message data is public data.

• Message data is queried at anytime after the market clears and the data is published.

9.11.29.12.2 Schema Template <EnergyLMP day="yyyy-mm-dd"> <EnergyLMPHourly hour="hh" [isDuplicateHour="true"]> <ELMP> <SettlementLocation>sss</SettlementLocation> <SettlementLocationType>sss</SettlementLocationType> <Pnode>sss</Pnode>


173

<LMP>99.99</LMP> </ELMP> </EnergyLMPHourly> </EnergyLMP>


<EnergyLMP> Complex Type Specifies the energy LMPs for the operating day. This element may be repeated as required to satisfy the query request.

day Date Specifies the operating day. <EnergyLMPHourly> Complex Type Specifies the data for the

specified hour-ending period. Repeated for each hour of the day, may occur zero to 25 times.



<ELMP> Complex Type Specifies the energy LMP value for the given location pricing node (pnode). This element is repeated for different locations.

<SettlementLocation> Settlement Location Identity

Specifies the settlement location identifier.

<SettlementLocationType>

Settlement Location Type

Specifies the resource type: PLT – plant GEN – generation unit CLD – controllable load LD – Load asset XGEN – generation unit external to the SPP footprint


174

Element or Attribute Data Type Description EXT – Aggregate pnode external to the SPP footprint

<Pnode> Pnode Name Specifies the location pricing node (pnode) name.

<LMP> Price Specifies the clearing price at the given location.

9.11.49.12.4 Example The following example shows an Energy LMP message for the given operating day. The SOAP wrapping XML is not shown in this example nor is the root element. <EnergyLMP day="2004-04-01"> <EnergyLMPHourly hour="12"> <ELMP> <SettlementLocation>LOCATION1</SettlementLocation> <SettlementLocationType>GEN</SettlementLocationType> <Pnode>PNODE1</Pnode> <LMP>23.50</LMP> </ELMP> <ELMP> <SettlementLocation>LOCATION2</SettlementLocation> <SettlementLocationType>GEN</SettlementLocationType> <Pnode>PNODE2</Pnode> <LMP>23.50</LMP> </ELMP> </EnergyLMPHourly> </EnergyLMP>

9.129.13 InvalidResourcePlan

9.12.19.13.1 Description The InvalidResourcePlan message notifies MPs that their submitted resource plan is invalid. This is private data. An invalid resource plan is generated when the plan violates the following rules:

• There is no resource plan entry for a given hour.

• The resource has an infeasible planned MW value when compared to the resource min and max values less the A/S Capacity Plan reserve designations.

This message is sent to participants using one of two methods:

1 Message is sent by notification when the resource plan is determined to be invalid.

2 Invalid resource plan messages may be queried at any time.


175

It is the MP's responsibility to correct their resource plan by resubmitting the plan to SPP.

Summary


• Message data is sent by notification to specified participants.

• Participants may query message data. There is no historical retention of these messages.

9.12.29.13.2 Schema Template <InvalidResourcePlan time="yyyy-mm-ddThh:mm:ss.SSS-zz:ZZ"> <Day>yyyy-mm-dd</Day> <Hour [isDuplicateHour="true"]>hh</Hour> <Resource>sss</Resource> <ResourceType>ttt</ResourceType> <Reason>sss</Reason> </InvalidResourcePlan>


<InvalidResourcePlan> Complex Type Specifies the invalid resource plan message issued at the given time.

time DateTime Specifies the time of issue of the message.

<Day> Date Specifies the date of the resource plan.

<Hour> Hour Ending Specifies the hour ending period of the plan in question.



<ResourceType> Resource Type Specifies the resource type:


176

Element or Attribute Data Type Description (PLT, GEN, CLD, XGEN)

PLT – plant GEN – generation unit CLD – controllable load XGEN – generation unit external to the SPP footprint

<Reason> Character Specifies the reason that the resource plan is invalid.

9.12.49.13.4 Example The following example shows an invalid resource plan message issued for the given day and hour. The SOAP wrapping XML is not shown in this example nor is the root element. <InvalidResourcePlan time="2004-05-01T13:02:01.000-06:00"> <Day>2004-05-02</Day> <Hour>7</Hour> <Resource>GEN1</Resource> <ResourceType>GEN</ResourceType> <Reason>Insufficiency</Reason> </InvalidResourcePlan>

9.139.14 MarketSchedule

9.13.19.14.1 Description The MarketSchedule message conveys to the participant the current schedule of submission gate closures for Resource Plans, AS Capacity Plans and EIS Offers for the next hour to close. Also sent are the schedules for the first and last AS Capacity Plan Mismatch and Invalid Resource Plan notifications for the day- ahead.

The Market Schedule events are referred to as a “market” by the MarketSchedule message, even though they may be a single point in time or representing what is not semantically known as a “market”. Each event contains:

• Start and end times for the operating period to which the event applies.

• Open and close times for the event itself. If the event is a single point in time the open and close times will be the same.

The following examples show the nominal events that may be contained in the <MarketSchedule> element:

• AS Capacity Plan submission deadlines for the next hour to close.


177

<Market> <MarketName>AS Capacity Plan Submission</MarketName> <OperatingStart>2004-04-29T00:00:00.000-06:00</OperatingStart> <OperatingEnd>2004-04-29T01:00:00.000-06:00</OperatingEnd> <MarketOpen>2004-04-22T07:00:00.000-06:00</MarketOpen> <MarketClose>2004-04-28T23:15:00.000-06:00</MarketClose> </Market>

• Resource Plan submission deadlines for the next hour to close. <Market> <MarketName>Resource Plan Submission</MarketName> <OperatingStart>2004-04-29T00:00:00.000-06:00</OperatingStart> <OperatingEnd>2004-04-29T01:00:00.000-06:00</OperatingEnd> <MarketOpen>2004-04-22T00:00:00.000-06:00</MarketOpen> <MarketClose>2004-04-28T23:15:00.000-06:00</MarketClose> </Market>

• EIS Offer submission deadlines for the next hour to close. <Market> <MarketName>EIS Offer Submission</MarketName> <OperatingStart>2004-04-29T00:00:00.000-06:00</OperatingStart> <OperatingEnd>2004-04-29T01:00:00.000-06:00</OperatingEnd> <MarketOpen>2004-04-22T00:00:00.000-06:00</MarketOpen> <MarketClose>2004-04-28T23:30:00.000-06:00</MarketClose> </Market>

• The scheduled time of the first and last day-ahead MismatchASCapacityPlan notifications.

<Market> <MarketName>First Mismatch Notification</MarketName> <OperatingStart>2004-04-29T00:00:00.000-06:00</OperatingStart> <OperatingEnd>2004-04-30T00:00:00.000-06:00</OperatingEnd> <MarketOpen>2004-04-28T11:00:00.000-06:00</MarketOpen> <MarketClose>2004-04-28T11:00:00.000-06:00</MarketClose> </Market> <Market> <MarketName>Last Mismatch Notification</MarketName> <OperatingStart>2004-04-29T00:00:00.000-06:00</OperatingStart> <OperatingEnd>2004-04-30T00:00:00.000-06:00</OperatingEnd> <MarketOpen>2004-04-28T13:00:00.000-06:00</MarketOpen> <MarketClose>2004-04-28T13:00:00.000-06:00</MarketClose> </Market>

• The scheduled time of the first and last day-ahead InvalidResourcePlan notifications.

<Market> <MarketName>First RPV Notification</MarketName> <OperatingStart>2004-04-29T00:00:00.000-06:00</OperatingStart> <OperatingEnd>2004-04-30T00:00:00.000-06:00</OperatingEnd> <MarketOpen>2004-04-28T11:00:00.000-06:00</MarketOpen> <MarketClose>2004-04-28T11:00:00.000-06:00</MarketClose> </Market> <Market> <MarketName>Last RPV Notification</MarketName> <OperatingStart>2004-04-29T00:00:00.000-06:00</OperatingStart> <OperatingEnd>2004-04-30T00:00:00.000-06:00</OperatingEnd> <MarketOpen>2004-04-28T13:00:00.000-06:00</MarketOpen> <MarketClose>2004-04-28T13:00:00.000-06:00</MarketClose> </Market>


178

The times at which each Market Schedule event will be sent are as follows:

• AS Capacity Plan and Resource Plan submission times will not be sent on a regular basis. These times are based on a constant offset of minutes from the top of the hour, and Market Schedule messages will only be sent containing them if this offset value is modified by a market operator. In this case the updated submission time for the upcoming hour will be sent in a Market Schedule message.

• EIS Offer submission times and the validation notification times are bound to events created for each day. These times will be sent in Market Schedule messages every day when the events are created. They will also be sent by exception when the timing any of these events is modified by a market operator.

9.13.29.14.2 Schema Template <MarketSchedule time="yyyy-mm-ddThh:mm:ss.SSS-zz:ZZ"> <Market> <MarketName>sss</MarketName> <OperatingStart>yyyy-mm-ddThh:mm:ss.SSS-zz:ZZ</OperatingStart> <OperatingEnd>yyyy-mm-ddThh:mm:ss.SSS-zz:ZZ</OperatingEnd> <MarketOpen>yyyy-mm-ddThh:mm:ss.SSS-zz:ZZ</MarketOpen> <MarketClose>yyyy-mm-ddThh:mm:ss.SSS-zz:ZZ</MarketClose> </Market> </MarketSchedule>

9.13.39.14.3 Data Description Element or Attribute Data Type Description <MarketSchedule> Complex Type Specifies the market schedule.time DateTime Specifies the time that the

message was issued (notifications issue time).

<Market> Complex Type Specifies the operating and data submittal periods for a given market.

<MarketName> Character Specifies the market name. <OperatingStart> DateTime Specifies the operating day

start. <OperatingEnd> DateTime Specifies the operating day

end. <MarketOpen> DateTime Specifies the data submittal

period open date and time. <MarketClose> DateTime Specifies the data submittal

period close date and time.


179

9.13.49.14.4 Example The following example shows the market schedule message for an EIS hourly market. The SOAP wrapping XML is not shown in this example nor is the root element. <MarketSchedule time="2004-04-29T00:00:00.000-06:00"> <Market> <MarketName>EIS Offer Submission</MarketName> <OperatingStart>2004-04-29T00:00:00.000-06:00</OperatingStart> <OperatingEnd>2004-04-29T01:00:00.000-06:00</OperatingEnd> <MarketOpen>2004-04-22T00:00:00.000-06:00</MarketOpen> <MarketClose>2004-04-28T23:30:00.000-06:00</MarketClose> </Market> </MarketSchedule>

9.149.15 MidtermLoadForecast

9.14.19.15.1 Description The MidtermLoadForecast message reports the best mid-term hourly load forecast for the date and time range and (optionally) for the given load area. This is public data.

Summary

• Message data is public.

• Message data can be queried at any time after it is published.

9.14.29.15.2 Schema Template <MidtermLoadForecast day="yyyy-mm-dd"> <LoadForecastHourly hour="hh" [isDuplicateHour="true"]> <Forecast> <ForecastMW>999</ForecastMW> <ForecastTime>yyyy-mm-ddThh:mm:ss.SSS-zz:ZZ</ForecastTime> <TotalMW>999</TotalMW> <LoadArea>sss</LoadArea> </Forecast> </LoadForecastHourly> </MidtermLoadForecast>


<MidtermLoadForecast> Complex Type Specifies the mid-term load forecast for the specified day on an hourly basis.

day Date Specifies the date of the midterm load forecast data.

<LoadForecastHourly> Complex Type Specifies the load forecast for


180

Element or Attribute Data Type Description the given hour.



<Forecast> Complex Type Specifies the forecast for a given load area. This element is repeated for each load area described by the hourly entry.

<ForecastMW> MW Specifies the forecast MW for the given hour ending.

<ForecastTime> DateTime Specifies the date and time of the forecast for this hour ending.

<TotalMW> MW System total MW for the hour (all load areas)

<LoadArea> Load Area Name Specifies the load area name for the forecast load. If not specified then there is no associated load area.

9.14.49.15.4 Example The following example shows the mid-term load forecast message for the given operating day. The SOAP wrapping XML is not shown in this example nor is the root element. <MidtermLoadForecast day="2004-04-29"> <LoadForecastHourly hour="1"> <Forecast> <ForecastMW>100</ForecastMW> <ForecastTime>2004-04-28T19:28:30.000-06:00</ForecastTime> <TotalMW>1200</TotalMW> <LoadArea>LA1</LoadArea> </Forecast> </LoadForecastHourly> <LoadForecastHourly hour="1"> <Forecast> <ForecastMW>100</ForecastMW> <ForecastTime>2004-04-28T19:28:30.000-06:00</ForecastTime>


181

<TotalMW>1200</TotalMW> <LoadArea>LA2</LoadArea> </Forecast> </LoadForecastHourly> <LoadForecastHourly hour="2"> <Forecast> <ForecastMW>100</ForecastMW> <ForecastTime>2004-04-28T19:28:30.000-06:00</ForecastTime> <TotalMW>1200</TotalMW> <LoadArea>LA1</LoadArea> </Forecast> </LoadForecastHourly> <LoadForecastHourly hour="2"> <Forecast> <ForecastMW>100</ForecastMW> <ForecastTime>2004-04-28T19:28:30.000-06:00</ForecastTime> <TotalMW>1200</TotalMW> <LoadArea>LA2</LoadArea> </Forecast> </LoadForecastHourly> </MidtermLoadForecast>

9.159.16 MismatchASCapacityPlan

9.15.19.16.1 Description The MismatchASCapacityPlan message notifies participants of a mismatch in submitted ancillary service capacity plan. This is private data. The mismatch is determined by matching obligations and resources among the counterparties to a plan schedule for a given hour. Any entry that is not matched by the counterparty is deemed to be mismatched and will result in a mismatch message being sent to both parties to the schedule.

It is possible that a mismatch can be fixed prior to a given participant receiving and processing the mismatch message. This is because two parties receive the message and one of those parties may be the responsible party to make the fix and the other party is subject to the fix.

There is no historical retention of mismatch messages. You may query only for outstanding mismatches.

This mismatch message is available by two methods:

1 The ancillary service capacity plan mismatch message is sent by notification at 1100 and 1300 day-ahead of the operating day and 45 minutes before the start of an operating hour, when there is a mismatch in the A/S Capacity Plan schedule. In the event that another MP is shown as a CounterParty and that CounterParty does not have an equal amount of obligation to the original MP, then a mismatch exists. Additionally, if the sum of the MP obligations in it’s A/S Capacity Plan is less than the SPP posted MP obligations, a mismatch exists. An MP may designate A/S


182

Obligations greater than or equal to the SPP posted MP obligations.28

2 The current outstanding ancillary service capacity plan mismatch messages may be queried at any time.

Summary


• Message data is sent by notification to specified participants.

• Participants may query message data.

9.15.29.16.2 Schema Template <MismatchASCapacityPlan time="yyyy-mm-ddThh:mm:ss.SSS-zz:ZZ"> <Day>yyyy-mm-dd</Day> <Hour [isDuplicateHour="true"]>hh</Hour> <ASScheduleCode>sss</ASScheduleCode> <ASProductCode>sss</ASProductCode> <ControlArea>sss</ControlArea> <Counterparty>sss</Counterparty> <CounterpartyType>sss</CounterpartyType> </MismatchASCapacityPlan>


<MismatchASCapacityPlan>

Complex Type Specifies the ancillary service capacity plan mismatch message issued at the given time.

time DateTime Specifies the time of issue of the mismatch message.

<Day> Date Specifies the date of the capacity plan.

<Hour> Hour Ending Specifies the hour ending period of the plan in question.

isDuplicateHour Boolean Specifies that the hour given above is the duplicate hour during the fall Daylight Saving Time transition to standard time. This attribute is optional and may not appear unless its value is



183

Element or Attribute Data Type Description true. The default value of false specifies that the hour is not a duplicate hour.

<ASScheduleCode> (Obligation, Resource)

Specifies the schedule type code.

<ASProductCode> (URS, DRS, SPIN, SUPP)

Specifies the ancillary service product code for the schedule. URS – up regulation service DRS – down regulation service SPIN – spinning reserve service SUPP – supplement service

<ControlArea> Control Area Name Specifies the control area name.

<Counterparty> Counterparty Identity

Specifies the counterparty to the capacity plan.

<CounterpartyType> Counterparty Type (TC)

Specifies the counterparty resource type. TC is the only counterparty type that is valid in this context. This represents what is referred to as the market participant or MP.

9.15.49.16.4 Example The following example shows an mismatch ancillary service capacity plan message issued for the given schedule. The SOAP wrapping XML is not shown in this example nor is the root element. <MismatchASCapacityPlan time="2004-05-01T13:02:01.000-06:00"> <Day>2004-05-02</Day> <Hour>7</Hour> <ASScheduleCode>Obligation</ASScheduleCode> <ASProductCode>URS</ASProductCode> <ControlArea>CA1</ControlArea> <Counterparty>TC1</Counterparty> <CounterpartyType>TC</CounterpartyType> </MismatchASCapacityPlan>

9.169.17 OperatorMessage

9.16.19.17.1 Description The OperatorMessage message is used to report emergency conditions and other operator messages to participants. A single


184

notification message may include more than one operator message. This is private data.

Summary



• Participants may query message data.

9.16.29.17.2 Schema Template <OperatorMessage> <EffectiveTime>yyyy-mm-ddThh:mm:ss.SSS-zz:ZZ</EffectiveTime> <TerminationTime>yyyy-mm-ddThh:mm:ss.SSS-zz:ZZ</TerminationTime> <Priority>ddd</Priority> <Realm>sss</Realm> <Text>sss</Text> </OperatorMessage>


<OperatorMessage> Complex Type Specifies an operator message for the given realm. This element may be repeated as required.

<EffectiveTime> DateTime Specifies the effective time for the message. Before this time specified, the message is not valid.

<TerminationTime> DateTime Specifies the termination time for the message. After this time specified, the message is not valid.

<Priority> Integer(0-999) Specifies the priority code as a number from 0 through 999. The lower the numeric value, the higher the priority. An emergency message has the priority code of 0.

<Realm> (Public,Private) Specifies the realm of the message.

<Text> Character(2000) A free-form textual message conveying the emergency condition or other operator message.


185

9.16.49.17.4 Example The following example shows an operator message for the given date, interval, and resource. The SOAP wrapping XML is not shown in this example nor is the root element which may be different depending on whether this is received as a notification or a query response.

<OperatorMessage> <EffectiveTime>2004-05-01T12:00:00.000-06:00</EffectiveTime> <TerminationTime>2004-05-02T11:59:59.000-06:00</TerminationTime> <Priority>2</Priority> <Realm>Private</Realm> <Text>Emergency rules are in effect for 24 hours</Text> </OperatorMessage>

9.179.18 OperatorOverride

9.17.19.18.1 Description The OperatorOverride message is issued whenever the market operator makes a change to a participant's submitted ancillary service capacity plan or resource plan.

Summary




9.17.29.18.2 Schema Template <OperatorOverride time="yyyy-mm-hhThh:mm:ss.SSS-zz:ZZ"> <DataChange plan="ppp" day="yyyy-mm-dd"> <OperatorName>sss</OperatorName> <Hour [isDuplicateHour="false"]>hh</Hour> <Description>ttt</Description> </DataChange> </OperatorOverride>


<OperatorOverride> Complex Type Specifies an operator data override message for the given plan, date, and hour. This element may be repeated as required.

time DateTime Specifies the operator


186

Element or Attribute Data Type Description override date and time.

<DataChange> Complex Type Specifies a single data change for the given plan type and plan date.

plan (ASCapacityPlan, ResourcePlan)

Plan type modified.

day Date Specifies the operational date for the plan.

<OperatorName> Character(30) Specifies the name of the market operator account that was used to make the change.

<Hour> Hour Ending Specifies the hour that has been modified.

isDuplicateHour Boolean Specifies that the hour ending is the duplicate hour of the fall Daylight Saving Time transition day. Optional, false if it does not appear meaning that it is not the duplicate hour.

<Description> Character(32767) Description of the data change. Self-explanatory from text.

9.17.49.18.4 Example The following example shows an Operator Override for the given plan and date.

<OperatorOverride time="2004-04-04T12:05:30.000-06:00"> <DataChange plan="ASCapacityPlan" day="2004-04-05"> <OperatorName>LRCON1</OperatorName> <Hour>15</Hour> <Description>Data change for ASCapacityPlan of product URS and control area CA1 and hour 15, Changed MW, New value is 23 old value was 21</Description> </DataChange> </OperatorOverride>

9.189.19 OverUnderCommitment

9.18.19.19.1 Description The OverUnderCommitment message is issued whenever an automated or manual validation of Participant Load Forecast,


187

Resource Plan and energy schedule data determines that an excess or deficient amount of capacity is available to satisfy the forecasted load. The calculations to determine over/undercommitment are as follows:

Overcommitment

In simplified terms an over commitment condition exists if all of the MP’s resources running at minimum capacity exceed the MP’s forecast load for that CA. The actual equation is as follows:

OverCommitmentAmount = MinEconomicAvailableCapacity + MinEconomicSelfScheduledCapacity – ForecastMW – ScheduledExport – MAX(ASDownRequirement, ASDownScheduledMW) + PlanManualMW

An overcommitment exists if OverCommitmentAmount is nonzero and positive.

See section 9.18.3 for details on each element of the calculation

Undercommitment

In simplified terms an under commitment condition exists if all of the MP’s resources running at maximum capacity cannot meet the MP’s forecast load for that CA. The actual equation is as follows:

UnderCommitmentAmount = MaxEconomicAvailableCapacity + MaxEconomicSelfScheduledCapacity + MaxEconomicSupplementalCapacity – ForecastMW – ScheduledExport – MAX(ASUpRequirement, ASUpScheduledMW) + PlanManualMW

An undercommitment exists if UnderCommitmentAmount is nonzero and negative.

See section 9.18.3 for details on each element of the calculation

These calculations will be performed on both the MP level and CA level (by aggregation of MP values). A notification will only be sent if an Over/Undercommitment exists at the CA level as well as the MP level.

Summary





188

9.18.29.19.2 Schema Template <OverUnderCommitment day="yyyy-mm-dd"> <Interval>hhmm</Interval> <ControlArea>ssss</ControlArea> <MinEconomicAvailableCapacityMW>

Nnnnn </MinEconomicAvailableCapacityMW> <MaxEconomicAvailableCapacityMW>

Nnnnn </MaxEconomicAvailableCapacityMW> <MinEconomicSelfScheduledCapacityMW>

nnnnn </MinEconomicSelfScheduledCapacityMW> <MaxEconomicSelfScheduledCapacityMW>

Nnnnn </MaxEconomicSelfScheduledCapacityMW> <MaxEconomicSupplementalCapacityMW>

Nnnnn </MaxEconomicSupplementalCapacityMW> <PlanManualMW>nnnnn</PlanManualMW> <ForecastMW>nnnnn</ForecastMW> <ScheduledExportMW>nnnnn</ScheduledExportMW> <ASUpRequirementMW>nnnnn</ASUpRequirementMW> <ASDownRequirementMW>nnnnn</ASDownRequirementMW> <ASUpScheduledMW>nnnnn</ASUpScheduledMW> <ASDownScheduledMW>nnnnn</ASDownScheduledMW> <OverUnderCommitmentMW>nnnnn</OverUnderCommitmentMW> <Reason>sssssssssss</Reason> </OverUnderCommitment>


<OverUnderCommitment>

Complex Type Specifies an Over/UnderCommitment message for the given date, hour, and Control Area. This element may be repeated as required.

day Date Specifies the operational date for the plan.


isDuplicateHour Boolean Specifies that the hour ending is the duplicate hour of the fall Daylight Saving Time transition day.


189

Element or Attribute Data Type Description Optional, false if it does not appear meaning that it is not the duplicate hour.

<ControlArea> Control Area Name Specifies the Control Area for which the validation was performed.

<MinEconomicAvailableCapacityMW>

Resource Plan MW The sum of all Resource Plan Min MW where status is “Available”

<MaxEconomicAvailableCapacityMW>

Resource Plan MW The sum of all Resource Plan Max MW where status is “Available”

<MinEconomicSelfScheduledCapacityMW>

Resource Plan MW The sum of all Resource Plan Min MW where status is “SelfScheduled”

<MaxEconomicSelfScheduledCapacityMW>

Resource Plan MW The sum of all Resource Plan Max MW where status is “SelfScheduled”

<MaxEconomicSupplementalCapacityMW>

Resource Plan MW The sum of all Resource Plan Max MW where status is “Supplemental”

<PlanManualMW> Resource Plan MW The sum of all Resource Plan MW where status is “Manual”

<ForecastMW> Forecast MW The MP submitted Load Forecast amount for the given hour and Control Area. This field is optional and will be omitted if the MP has not submitted a load forecast.

<ScheduledExportMW> Schedule MW The net amount of all energy schedules, excluding Payback schedules, where the source or sink is owned by the MP

<ASUpRequirementMW> AS Obligation MW The sum of RTO assigned URS, SPIN and SUPP requirements for this MP for the given Control Area

<ASDownRequirementMW>

AS Obligation MW The RTO assigned DRS requirement for this MP for the given Control Area


190

Element or Attribute Data Type Description <ASUpScheduledMW> AS scheduled MW MP scheduled AS Capacity

for URS, SPIN and SUPP service types

<ASDownScheduledMW> AS Scheduled MW MP scheduled AS Capacity for DRS service types

<OverUnderCommitmentMW>

OverUnderCommitmentMW

The nonzero result of the calculation that determined the over/under commitment

<Reason> OverUnderCommitmentReason

A text message describing whether there is an over or undercommitment

9.18.49.19.4 Example The following example shows an OverUnderCommitment for a specific day, interval and control area: <OverUnderCommitment day="2004-03-06"> <Interval>1105</Interval> <ControlArea>CA1</ControlArea> <MinEconomicAvailableCapacityMW>

100 </MinEconomicAvailableCapacityMW> <MaxEconomicAvailableCapacityMW>

1000 </MaxEconomicAvailableCapacityMW> <MinEconomicSelfScheduledCapacityMW>

0 </MinEconomicSelfScheduledCapacityMW> <MaxEconomicSelfScheduledCapacityMW>

0 </MaxEconomicSelfScheduledCapacityMW> <MaxEconomicSupplementalCapacityMW>

0 </MaxEconomicSupplementalCapacityMW> <PlanManualMW>0</PlanManualMW> <ForecastMW>800</ForecastMW> <ScheduledExportMW>0</ScheduledExportMW> <ASUpRequirementMW>250</ASUpRequirementMW> <ASDownRequirementMW>100</ASDownRequirementMW> <ASUpScheduledMW>250</ASUpScheduledMW> <ASDownScheduledMW>100</ASDownScheduledMW> <OverUnderCommitmentMW>-50</OverUnderCommitmentMW> <Reason> Participant has an Undercommitment of 50 MW. </Reason> </OverUnderCommitment>


191

9.199.20 ParticipantLoadForecast

9.19.19.20.1 Description The ParticipantLoadForecast message is used by MPs to submit their hourly Load Forecast values for each Control Area in which they have load assets. This message is private data.

ParticipantLoadForecast data is used to validate Resource Plan and energy schedule data to determine a capacity over/undercommitment. See section 9.18.1 for details on this validation.

An MP can only submit a ParticipantLoadForecast for a Control Area in which they have at least one load asset.

Summary


• Message data is submitted no sooner than 7 days ahead of the operating day.

• Submitted data may be updated until 45 minutes before the start of the operating hour. Updates include replacing a submitted forecast for a given hour and Control Area (delete is not supported).



9.19.29.20.2 Schema Template <ParticipantLoadForecast day="yyyy-mm-dd"> <ParticipantLoadForecastHourly hour="hh" [isDuplicateHour="true"]> <ParticipantLoadForecastDetail> <ControlArea>ssss</ControlArea> <ForecastMW>nnn</ForecastMW> </ParticipantLoadForecastDetail> </ParticipantLoadForecastHourly> </ParticipantLoadForecast>


<ParticipantLoadForecast>

Complex Type Specifies the Load Forecast for the given day. This element may be repeated for other operating days.


192

Element or Attribute Data Type Description day Date Specifies the operating day of

the resource plan. <ParticipantLoadFore

castHourly>

Complex Type Specifies the Load Forecast for the specified hour-ending period.



<ParticipantLoadForecastDetail>

Complex Type Specifies a load forecast detail for a given Control Area.


Specifies the Control Area for this detail

<ForecastMW> Forecast MW Specifies the Load Forecast amount for this Control Area

9.19.49.20.4 Example The following example shows a ParticipantLoadForecast for the given date, hour, and Control Area. The SOAP wrapping XML is not shown in this example nor is the root element shown.

<ParticipantLoadForecast day="2006-01-01"> <ParticipantLoadForecastHourly hour="1"> <ParticipantLoadForecastDetail> <ControlArea>CA1</ControlArea> <ForecastMW>500</ForecastMW> </ParticipantLoadForecastDetail> </ParticipantLoadForecastHourly> </ParticipantLoadForecast>


193

9.209.21 Ping

9.20.19.21.1 Description The Ping message is sent by the SPP RTO periodically to participant web listener registered addresses. The purpose of the Ping is to test and validate the operation of the network channel and the web listener provided by the participant.

The participant responds to a ping with an ACK type response just the same as any other message. Any failure to receive an ACK results in an alert message to the market operator. The participant can force such an alert by sending a NAK or the alert is raised if the ping fails due to connection failure or timeout.

Summary

• Message does not contain any data.

• Message is sent to participants who have registered listeners with SPP.

• There is no query support for ping messages.

9.20.29.21.2 Schema Template <Ping time="yyyy-mm-ddThh:mm:ss.SSS-zz:ZZ"/>


<Ping> Singleton Type Specifies the Ping message singleton that includes the current date and time of issue.

time DateTime Specifies the date and time of the ping issue.

9.20.49.21.4 Example The following example shows an Ping for the given date, interval, and resource. The SOAP wrapping XML is not shown in this example nor is the root element shown. <Ping day="2004-04-01T08:00:12.000-06:00"/>


194

9.219.22 ResourcePlan

9.21.19.22.1 Description The ResourcePlan message is used by MPs to submit the hourly resource plan for each resource. Resources include both generators and controllable loads. This message is private data.

Resource operation limits are specified for both economic and emergency operations. During typical market operation the economic values will be used by the market system for generating dispatch instructions. During an emergency situation operators will take advantage of the emergency limits to manually deploy the resources

Ramp rate limits are specified as a multi-segment profile. Each segment specifies a breakpoint MW level indicating the level at or above which the ramp rate limits for that segment apply. Each segment specifies an up directional ramp rate limit, a down directional ramp rate limit and and emergency operation ramp rate limit. The profile must include at least one segment. Ramp profile segments do not need to be submitted in increasing order, but they will be re-ordered when stored such that the segments are increasing by their breakpoint limit MW.

The following validations will be performed on submitted ramp rate profiles:

• A given breakpoint MW cannot be specified more than once

• EmergencyRampRate must be > 0

• EmergencyRampRate must be >= UpRampRate

• EmergencyRampRate must be >= DownRampRate

• All ramp rates must be > 0 if the plan status is SelfScheduled

Resource plans are measured as valid or invalid when tested with other market data. A participant is notified of an invalid Resource Plan via an InvalidResourcePlan (see section 9.12) message sent by a notification to the MP. Such messages can also be queried after they are published. Resource plans must cover all hours of the operating day.

The relationship required between the limits and the plan MW are:

• PlanMW is greater than or equal to MinEconomicMW unless PlanMW is zero.

• PlanMW is less than or equal to MaxEconomicMW.


195

The relationships required among each of the limits are:

• MinEconomicMW >= MinMW >= MinEmergencyrMW.

• MaxEconomicMW <= MaxMW <= MaxEmergencyMW.

• All min ratings (MinMW, MinEconomicMW, MinEmergencyMW) >= 0 unless plan status is SelfScheduled.

The operating status (see ResourceStatus element below) has the following meaning:

• Available – Resource is online and available for SPP Deployment.

• QuickStart – Resource is certified as a Quick Start unit and is available for SPP Deployment even if it is offline or the breaker is open. Resource is capable of carrying Supplemental Ancillary Services but not Regulation Up, Regulation Down, or Spinning Reserves.

• Unavailable – Resource is offline and unavailable for SPP Deployment or other uses.

• Supplemental – Resource is offline and available for satisfying Supplemental Reserve requirements. The Resource will NOT be dispatched by the MOS system.

• Intermittent – Resource is certified as an Intermittent unit not capable of following Dispatch Instructions or adhering to a Schedule because it is an Intermittent Resource. Resource is permitted to report Ancillary Services if the limitations on their ability to follow Dispatch Instructions or adhere to their Schedules do not preclude them from providing said Ancillary Services.

• Startup – Resource is not capable of following Dispatch Instructions or adhering to a Schedule because it is currently starting up. Resource is permitted to report Ancillary Services if the limitations on their ability to follow Dispatch Instructions or adhere to their Schedules do not preclude them from providing said Ancillary Services.

• Shutdown – Resource is not capable of following Dispatch Instructions or adhering to a Schedule because it is currently shutting down. Resource is permitted to report Ancillary Services if the limitations on their ability to follow Dispatch Instructions or adhere to their Schedules do not preclude them from providing said Ancillary Services.


196

• Testing – Resource is not capable of following Dispatch Instructions or adhering to a Schedule due to unit testing. Resource is permitted to report Ancillary Services if the limitations on their ability to follow Dispatch Instructions or adhere to their Schedules do not preclude them from providing said Ancillary Services.

• QualifyingFacility – Resource is certified as a Qualifying Facility and is not capable of following Dispatch Instructions or adhering to a Schedule due to unit testing. Resource is permitted to report Ancillary Services if the limitations on their ability to follow Dispatch Instructions or adhere to their Schedules do not preclude them from providing said Ancillary Services.

• ExigentConditions – Resource is not capable of following Dispatch Instructions or adhering to a Schedule due to sudden changes in generator conditions or operating characteristics that prevent predictable resource operation. Resource is permitted to report Ancillary Services if the limitations on their ability to follow Dispatch Instructions or adhere to their Schedules do not preclude them from providing said Ancillary Services.

Note: This status will only be accepted when submitted by a Market Operator as an Override.

• SelfScheduled – Resource is online and unavailable for SPP Deployment.

A resource plan is measured to be invalid if:

• A given hour is not covered by a resource plan entry for a resource. All hours must include an entry even if the unit is offline and producing zero MW.

• Resource MW limit is under or over production for a given hour when compared with other obligations and ancillary service plan schedules.

Summary


• Message data is submitted no sooner than 7 days ahead of the operating day.

• Submitted data may be updated until 45 minutes before the start of the operating hour. Updates include replacing a submitted plan (delete is not supported).


197



9.21.29.22.2 Schema Template <ResourcePlan resource="sss" type="ttt" day="yyyy-mm-dd" [valid="true"]> <ResourcePlanHourly hour="hh" [isDuplicateHour="true"]> <ResourceStatus>sss</ResourceStatus> <PlanMW>ddd</PlanMW> <MinMW>ddd</MinMW> <MinEconomicMW>ddd</MinEconomicMW> <MinEmergencyMW>ddd</MinEmergencyMW> <MaxMW>ddd</MaxMW> <MaxEconomicMW>ddd</MaxEconomicMW> <MaxEmergencyMW>ddd</MaxEmergencyMW> <RampRateProfile> <RampRateBreakpoint> <BreakpointLimit>ddd</BreakpointLimit> <RampRateUp>ddd.dd</RampRateUp> <RampRateDown>ddd.dd</RampRateDown> <RampRateEmergency>ddd.dd</RampRateEmergency> </RampRateBreakpoint> </RampRateProfile> </ResourcePlanHourly> </ResourcePlan>


<ResourcePlan> Complex Type Specifies the resource plan for the specified resource and operating day. This element may be repeated for other resources and/or operating day dates.




day Date Specifies the operating day of the resource plan.

<ResourcePlanHourly> Complex Type Specifies the resource plan for the specified hour-ending period.


198

Element or Attribute Data Type Description hour Hour Ending Specifies the hour-ending of

the day from 01 through 24. isDuplicateHour Boolean Specifies that the hour given

above is the duplicate hour during the fall Daylight Saving Time transition to standard time. This attribute is optional and may not appear unless its value is true. The default value of false specifies that the hour is not a duplicate hour.

<ResourceStatus> (Unavailable, Spplemental, SelfScheduled, Available, QuickStart, Intermittent, Startup, Shutdown, Testing, QualifyingFacility, ExigentConditions)

Specifies the operating status of the resource. Required element.

<PlanMW> MW Specifies the plan MW for this hourly period. Required element.

<MinMW> MW Specifies the minimum MW for this hourly period. Required element.

<MaxMW> MW Specifies the maximum MW for this hourly period. Required element.

<MinEconomicMW> MW Specifies the minimum MW for this hourly period during economic operation. Required element.

<MinEmergencyMW> MW Specifies the minimum MW for this hourly period during emergency operation. Required element.

<MaxEconomicMW> MW Specifies the maximum MW


199

Element or Attribute Data Type Description for this hourly period during economic operation. Required element.

<MaxEmergencyMW> MW Specifies the maximum MW for this hourly period during emergency operation. Required element.

<RampRateProfile> Complex Type Specifies the ramp rate in MW per minute for this hourly period at specified output levels and modes of operation. Required element.

<RampRateBreakpoint> Complex Type Specifies the up, down and emergency ramp rates at or above a given breakpoint MW limit

<BreakpointLimit> MW Specifies the MW output level at or above which the following ramp rate limits apply.

<RampRateUp> MW Rate Specifies the ramp rate limit when increasing generation output during economic operation

<RampRateDown> MW Rate Specifies the ramp rate limit when decreasing generation output during economic operation

<RampRateEmergency> MW Non Zero Rate

Specifies the ramp rate limit when altering generation output during emergency operation.

9.21.49.22.4 Example The following example shows a Resource Plan for the given date, hour, and resource. The SOAP wrapping XML is not shown in this example nor is the root element shown.

<ResourcePlan resource="GEN1" type="GEN" day="2004-05-01"> <ResourcePlanHourly hour="1"> <ResourceStatus>Available</ResourceStatus> <PlanMW>125</PlanMW> <MinMW>20</MinMW>


200

<MinEconomicMW>20</MinEconomicMW> <MinEmergencyMW>20</MinEmergencyMW> <MaxMW>180</MaxMW> <MaxEconomicMW>180</MaxEconomicMW> <MaxEmergencyMW>180</MaxEmergencyMW> <RampRateProfile> <RampRateBreakpoint> <BreakpointLimit>0</BreakpointLimit> <RampRateUp>10</RampRateUp> <RampRateDown>10</RampRateDown> <RampRateEmergency>15</RampRateEmergency> </RampRateBreakpoint> <RampRateBreakpoint> <BreakpointLimit>50</BreakpointLimit> <RampRateUp>15</RampRateUp> <RampRateDown>15</RampRateDown> <RampRateEmergency>20</RampRateEmergency> </RampRateBreakpoint> </RampRateProfile> </ResourcePlanHourly> <ResourcePlanHourly hour="2"> <ResourceStatus>Available</ResourceStatus> <PlanMW>125</PlanMW> <MinMW>20</MinMW> <MinEconomicMW>20</MinEconomicMW> <MinEmergencyMW>20</MinEmergencyMW> <MaxMW>180</MaxMW> <MaxEconomicMW>180</MaxEconomicMW> <MaxEmergencyMW>180</MaxEmergencyMW> <RampRateProfile> <RampRateBreakpoint> <BreakpointLimit>0</BreakpointLimit> <RampRateUp>10</RampRateUp> <RampRateDown>10</RampRateDown> <RampRateEmergency>15</RampRateEmergency> </RampRateBreakpoint> <RampRateBreakpoint> <BreakpointLimit>50</BreakpointLimit> <RampRateUp>15</RampRateUp> <RampRateDown>15</RampRateDown> <RampRateEmergency>20</RampRateEmergency> </RampRateBreakpoint> </RampRateProfile> </ResourcePlanHourly> <ResourcePlanHourly hour="3"> <ResourceStatus>Available</ResourceStatus> <PlanMW>125</PlanMW> <MinMW>20</MinMW> <MinEconomicMW>20</MinEconomicMW> <MinEmergencyMW>20</MinEmergencyMW> <MaxMW>180</MaxMW> <MaxEconomicMW>180</MaxEconomicMW> <MaxEmergencyMW>180</MaxEmergencyMW> <RampRateProfile> <RampRateBreakpoint> <BreakpointLimit>0</BreakpointLimit> <RampRateUp>10</RampRateUp> <RampRateDown>10</RampRateDown> <RampRateEmergency>15</RampRateEmergency> </RampRateBreakpoint> <RampRateBreakpoint> <BreakpointLimit>50</BreakpointLimit> <RampRateUp>15</RampRateUp>


201

<RampRateDown>15</RampRateDown> <RampRateEmergency>20</RampRateEmergency> </RampRateBreakpoint> </RampRateProfile> </ResourcePlanHourly> </ResourcePlan>

9.229.23 SelfDispatchMaxViolation

9.22.19.23.1 Description The SelfDispatchMaxViolation message conveys data on self dispatch resources that failed to pass validation of schedules against RP and ASCP values by exceeding the adjusted resource max Economic MW. In most circumstances, a violation will occur when the sum of the scheduled amounts is greater than the Resource Plan Max Economic MW + A/S Plan URS + A/S Plan SUPP + A/S Plan SPIN. In the event that a resource actual MW value exceeds its Resource Plan Max Economic MW, then the Resource Plan Max Economic MW is raised in the above equation.

SelfDispatchMaxViolation messages will be sent at the time of the validation, which occurs for each hour at the time when the deadlines for that hour for submitting AS Capacity Plans, Resource Plans and operator overrides have passed. Incremental validations are also performed within 1 minute of detecting any change to schedule data for an already closed hour.

Summary




9.22.29.23.2 Schema Template <SelfDispatchMaxViolation day="yyyy-mm-dd" interval="hhmm" [isDuplicateHour="true"] <Resource>sss</Resource> <ResourceType>sss</ResourceType> <ScheduleTotalMW>999</ScheduleTotalMW> <MaxEconomicMW>999</MaxEconomicMW> <SPINMW>999</SPINMW> <SUPPMW>999</SUPPMW> <URSMW>999</URSMW> </SelfDispatchMaxViolation>


<SelfDispatchMaxViolation>

Complex Type Specifies the self dispatch max violation for the specified day


202

Element or Attribute Data Type Description on an 5-minute interval basis.

day Date Specifies the date of the short term load forecast.

interval Interval Ending Specifies the 5-minute interval-ending of the day from 0005 through 2400.


<Resource> Resource Identity


<Type> Internal Resource Type (PLT, GEN, CLD)


<ScheduleTotalMW> MW Specifies the sum of all energy schedules for this resource and interval

<MaxEconomicMW> MW Specifies the Max Economic MW from the Resource Plan for this resource

<SPINMW> MW Specifies the SPIN MW from the AS Capacity Plan for this resource

<SUPPMW> MW Specifies the SUPP MW from the AS Capacity Plan for this resource

<URSMW> MW Specifies the URS MW from the AS Capacity Plan for this resource

9.22.49.23.4 Example The following example shows the self dispatch max violation message for the given resource and interval. The SOAP wrapping XML is not shown in this example nor is the root element.


203

<SelfDispatchMaxViolation day="2005-01-01" interval="115"> <Resource>GEN1</Resource> <ResourceType>GEN</ResourceType> <ScheduleTotalMW>999</ScheduleTotalMW> <MaxEconomicMW>999</MaxEconomicMW> <SPINMW>999</SPINMW> <SUPPMW>999</SUPPMW> <URSMW>999</URSMW> </SelfDispatchMaxViolation>

9.239.24 SelfDispatchMinViolation

9.23.19.24.1 Description The SelfDispatchMinViolation message conveys data on self dispatch resources that failed to pass validation of schedules against RP and ASCP values by falling short of the adjusted resource min Economic MW. In most circumstances, a violation will occur when the sum of the scheduled amounts is less than the Resource Plan Min Economic MW + A/S Plan DRS. In the event that a resource actual MW value is less than its Resource Plan Min Economic MW, then the Resource Plan Min Economic MW is lowered in the above equation.

SelfDispatchMinViolation messages will be sent at the time of the validation, which occurs for each hour at the time when the deadlines for that hour for submitting AS Capacity Plans, Resource Plans and operator overrides have passed. Incremental validations are also performed within 1 minute of detecting any change to schedule data for an already closed hour.

Summary




9.23.29.24.2 Schema Template <SelfDispatchMinViolation day="yyyy-mm-dd" interval="hhmm" [isDuplicateHour="true"]> <Resource>sss</Resource> <ResourceType>sss</ResourceType> <ScheduleTotalMW>999</ScheduleTotalMW> <MinEconomicMW>999</MinEconomicMW> <DRSMW>999</DRSMW> </SelfDispatchMinViolation>



204

Element or Attribute Data Type Description <SelfDispatchMaxViolati

on> Complex Type Specifies the self dispatch max

violation for the specified day on an 5-minute interval basis.




<Resource> Resource Identity


<Type> Internal Resource Type (PLT, GEN, CLD)


<ScheduleTotalMW> MW Specifies the sum of all energy schedules for this resource and interval

<MinEconomicMW> MW Specifies the Min Economic MW from the Resource Plan for this resource

<DRSMW> MW Specifies the DRS MW from the AS Capacity Plan for this resource

9.23.49.24.4 Example The following example shows the self dispatch min violation message for the given resource and interval. The SOAP wrapping XML is not shown in this example nor is the root element.

<SelfDispatchMinViolation day="2005-01-01" interval="115"> <Resource>GEN1</Resource> <ResourceType>GEN</ResourceType>


205

<ScheduleTotalMW>999</ScheduleTotalMW> <MinEconomicMW>999</MinEconomicMW> <DRSMW>999</DRSMW> </SelfDispatchMinViolation>

9.249.25 ShorttermLoadForecast

9.24.19.25.1 Description The ShorttermLoadForecast message reports the short-term load forecast for the date and 5-minute interval. This is public data.

Summary

• Message data is public.

• Message data can be queried at any time after it is published.

9.24.29.25.2 Schema Template <ShorttermLoadForecast day="yyyy-mm-dd"> <LoadForecastInterval interval="hhmm" [isDuplicateHour="true"]> <Forecast> <ForecastMW>999</ForecastMW> <ForecastTime>yyyy-mm-ddThh:mm:ss.SSS-zz:ZZ</ForecastTime> <TotalMW>999</TotalMW> <LoadArea>sss</LoadArea> </Forecast> </LoadForecastInterval> </ShorttermLoadForecast>


<ShorttermLoadForecast> Complex Type Specifies the short-term load forecast for the specified day on an 5-minute interval basis.


<LoadForecastInterval> Complex Type Specifies the load forecast for the given 5-minute interval.


isDuplicateHour Boolean Specifies that the hour given above is the duplicate hour during the fall Daylight Saving Time transition to standard time. This attribute is optional and may not appear unless its


206

Element or Attribute Data Type Description value is true. The default value of false specifies that the hour is not a duplicate hour.

<Forecast> Complex Type Specifies the forecast for a given load area. Repeated for each load area of the interval.

<ForecastMW> MW Specifies the forecast MW for the given interval.

<Forecast> DateTime Specifies the date and time of the last forecast for the given interval.

<TotalMW> MW System total MW for the hour (all load areas)

<LoadArea> Load Area Name

Specifies the load area name for the forecast load. If not specified then there is no associated load area.

9.24.49.25.4 Example The following example shows the short-term load forecast message for the given operating day. The SOAP wrapping XML is not shown in this example nor is the root element.

<ShorttermLoadForecast day="2004-04-29"> <LoadForecastInterval interval="115"> <Forecast> <ForecastMW>100</ForecastMW> <ForecastTime>2004-04-28T19:28:30.000-06:00</ForecastTime> <TotalMW>1200</TotalMW> <LoadArea>LA1</LoadArea> </Forecast> </LoadForecastInterval> <LoadForecastInterval interval="115"> <Forecast> <ForecastMW>100</ForecastMW> <ForecastTime>2004-04-28T19:28:30.000-06:00</ForecastTime> <TotalMW>1200</TotalMW> <LoadArea>LA2</LoadArea> </Forecast> </LoadForecastInterval> <LoadForecastInterval interval="130"> <Forecast> <ForecastMW>100</ForecastMW> <ForecastTime>2004-04-28T19:28:30.000-06:00</Forecast> <TotalMW>1200</TotalMW> <LoadArea>LA1</LoadArea> </Forecast> </LoadForecastInterval>


207

<LoadForecastInterval interval="130"> <Forecast> <ForecastMW>100</ForecastMW> <ForecastTime>2004-04-28T19:28:30.000-06:00</ForecastTime> <TotalMW>1200</TotalMW> <LoadArea>LA2</LoadArea> </Forecast> </LoadForecastInterval> </ShorttermLoadForecast>

9.259.26 URDInterval

9.25.19.26.1 Description The URDInterval message is used to notify market participants of the results of Uninstructed Resource Deviation (URD) calculations for a given resource and interval ending time. This message conveys private data.

The URD interval message is sent as part of a Notifications message pushed to participants having registered resource assets. The URDInterval notification will be issued at the end of that dispatch interval for every resource whether or not a violation has occurred. Messages will continue to be sent for each interval, regardless of the lock status on the resource. URDInterval data is also available by query.

Summary





9.25.29.26.2 Schema Template <URDInterval day="yyyy-mm-dd" interval="hhmm" [isDuplicateHour="true"]> <Resource>sss</Resource> <ResourceType>sss</ResourceType> <URDMW>ddd</URDMW> <DispatchMW>ddd</DispatchMW> <GenerationMW>ddd</GenerationMW> <URDUpRegulationMW>ddd</URDUpRegulationMW> <URDDownRegulationMW>ddd</URDDownRegulationMW> <URDWaiver>true</URDWaiver> <URDIntervalViolated>true</URDIntervalViolated> <URDReason>sssss</URDReason> <URDViolations>d</URDViolations> </URDInterval>


208


<URDInterval> Complex Type Specifies the URDInterval message for the associated resource.

day Date Specifies the day of the interval ending.





<URDMW> URD MW Specifies the calculated URD megawatt value as specified in the latest version of the Market Protocols.

<DispatchMW> MW Specifies the dispatched megawatt value, regardless of whether the resource is self-dispatched or available to the market.

<GenerationMW> MW Specifies the actual generated megawatt value as received from the ICCP real-time metering entity.

<URDUpRegulationMW> URD MW Specifies the Up Regulation Service megawatt value from


209

Element or Attribute Data Type Description the AS Capacity Plan.

<URDDownRegulationMW> URD MW Specifies the Down Regulation Service megawatt value from the AS Capacity Plan.

<URDWaiver> Boolean Specifies whether a violation waiver was given for this URD interval.

<URDIntervalViolated> Boolean Specifies whether URD calculations resulted in a violation for this URD interval and resource.

<URDReason> URDReason Specifies the reason for the waiver or violation, or communicates the absence of a violation: • FollowingDispatch – No

violation was found. • SolutionMissing – No RTB

solution for this interval • ScadaMissing – No

SCADA values for this interval

• ScadaBad – SCADA quality indicator was bad for this interval

• ArsEvent – Reserve sharing scheduled on this interval for this resource

• Non-Dispatchable ResourceManualResourcePlan – Resource plan submitted or overridden to Manual status for this resourceThis is a Non dispatchable resource

• NotFollowingDispatch – Indicates a URD violation that was not waived

• AuxLoadOrPumping – Indicates a resource that is consuming rather than generating energy and had


210

Element or Attribute Data Type Description either negative SCADA value or negative dispatch for this interval

• OomeDispatch – Indicates an Out-Of-Merit-Energy, or manual, dispatch was issued by an operator for this interval

• RampRateViolationNotCausedByAS – Indicates a ramp rate violation occurred that was not caused by an ancillary service assignment

<URDViolations> Integer (0–999999)

Specifies the number of consecutive intervals in which violations have occurred at the specified interval.

9.25.49.26.4 Example The following example shows a URDInterval. The SOAP wrapping XML is not shown in this example nor is the root element which may be different depending on whether this is received as a notification or a query response. <URDInterval day="2005-03-10" interval="1000"> <Resource>GEN1</Resource> <ResourceType>GEN</ResourceType> <URDMW>2</URDMW> <DispatchMW>50</DispatchMW> <GenerationMW>60</GenerationMW> <URDUpRegulationMW>3</URDUpRegulationMW> <URDDownRegulationMW>3</URDDownRegulationMW> <URDWaiver>true</URDWaiver> <URDIntervalViolated>true</URDIntervalViolated> <URDReason>ManualResourcePlan</URDReason> <URDViolations>6</URDViolations> </URDInterval>

9.269.27 URDResourceLocked

9.26.19.27.1 Description The URDResourceLocked message is used to notify resource owners that a resource is locked out of the market. Reference the Market Protocols for the latest rules around the criteria for receiving


211

a Resource locked or unlocked message. This message conveys private data.

The resource locked message is sent as part of a Notifications message pushed to named participants. URDResourceLocked will be issued only at the end of the dispatch interval which caused the resource to be locked. URDResourceLocked is also available by query.

Summary





9.26.29.27.2 Schema Template <URDResourceLocked day="yyyy-mm-dd" interval="hhmm" [isDuplicateHour="true"]> <Resource>sss</Resource> <ResourceType>sss</ResourceType> <LockExpiresDay>yyyy-mm-dd</LockExpiresDay> <LockExpiresInterval [isDuplicate="true"]>hhmm</LockExpiresInterval> </URDResourceLocked>


<URDResourceLocked> Complex Type Specifies the URDResourceLocked message for the associated resource.

day Date Specifies the day of the interval ending in which the lock out takes effect.

interval Interval Ending Specifies the 5-minute interval-ending of the day from 0005 through 2400 in which the URD lockout began.

isDuplicateHour Boolean Specifies that the hour given above is the duplicate hour during the fall Daylight Saving Time transition to standard time. This attribute is optional and may not appear unless its


212

Element or Attribute Data Type Description value is true. The default value of false specifies that the hour is not a duplicate hour.



<LockExpiresDay> Date Specifies the day of the interval ending in which the lock expires.

<LockExpiresInterval> Interval Ending Specifies the last 5-minute interval-ending of the day from 0005 through 2400 of which the lock is effective.


9.26.49.27.4 Example The following example shows a URDResourceLocked message. The SOAP wrapping XML is not shown in this example nor is the root element which may be different depending on whether this is received as a notification or a query response. <URDResourceLocked day="2005-03-10" interval="1000"> <Resource>GEN1</Resource> <ResourceType>GEN</ResourceType> <LockExpiresDay>2005-03-12</LockExpiresDay> <LockExpiresInterval>1000</LockExpiresInterval> </URDResourceLocked>


213

9.279.28 ReturningURDLockedResource

9.27.19.28.1 Description The returningURDLockedResource message is used to notify resource owners that a resource that has been locked out of the market is going to be returned to the market. This message will be sent out a configured number of intervals before the resource is to be unlocked. Reference the Market Protocols for the number of intervals, and the latest rules around the criteria for receiving a ReturningURDLockedResource message. This message conveys private data.

The returning locked resource message is sent as part of a Notifications message pushed to named participants. This data is not available by query.

Summary



• There is no participant query, submittal or update of this data.

9.27.29.28.2 Schema Template <ReturningURDLockedResource day="yyyy-mm-dd" interval="hhmm" [isDuplicateHour="true"]> <Resource>sss</Resource> <ResourceType>sss</ResourceType> <LockExpiresDay>yyyy-mm-dd</LockExpiresDay> <LockExpiresInterval [isDuplicate="true"]>hhmm</LockExpiresInterval> </ReturningURDLockedResource>


<ReturningURDLockedResource>

Complex Type Specifies the ReturningURDLockedResource message for the associated resource.

day Date Specifies the day of the interval ending in which the lock out takes effect.

interval Interval Ending Specifies the 5-minute interval-ending of the day from 0005 through 2400 in which the URD lockout began.


214

Element or Attribute Data Type Description isDuplicateHour Boolean Specifies that the hour given

above is the duplicate hour during the fall Daylight Saving Time transition to standard time. This attribute is optional and may not appear its value is true. The default value of false specifies that the hour is not a duplicate hour.



<LockExpiresDay> Date Specifies the day of the interval ending in which the lock expires.

<LockExpiresInterval> Interval Ending Specifies the last 5-minute interval-ending of the day from 0005 through 2400 of which the lock is effective.


9.27.49.28.4 Example The following example shows a ReturningURDLockedResource message. The SOAP wrapping XML is not shown in this example nor is the root element which may be different depending on whether this is received as a notification or a query response. <ReturningURDLockedResource day="2005-03-10" interval="1000"> <Resource>GEN1</Resource> <ResourceType>GEN</ResourceType> <LockExpiresDay>2005-03-12</LockExpiresDay>


215

<LockExpiresInterval>1000</LockExpiresInterval> </ReturningURDLockedResource>

9.289.29 URDResourceUnlocked

9.28.19.29.1 Description The URDResourceUnlocked message is used to notify resource owners that a resource that has previously been locked out is now unlocked and back in the market. A URDResourceUnlocked message may be sent when the lock expires or when the market operator issues a manual unlock. This message conveys private data.

SD resources are not subject to URD lockouts. They may still receive URD lockout and violation notifications, but will continue to be dispatched normally. However, if an SD resource that has been locked is switched from “SelfScheduled” Resource Plan status for an hour in which it is locked out, it will again become subject to all URD-related protocols.

The resource unlocked message is sent as part of a Notifications message pushed to named participants. URDResourceUnlocked will be issued following the calculation of the Dispatch Interval immediately preceding the Dispatch Interval that the resource is being released. URDResourceUnlocked is also available by query.

Summary





9.28.29.29.2 Schema Template <URDResourceUnlocked type="sss" day="yyyy-mm-dd" interval="hhmm" [isDuplicateHour="true"]> <Resource>sss</Resource> <ResourceType>sss</ResourceType> </URDResourceUnlocked>


<URDResourceUnlocked> Complex Type Specifies the URDResourceUnlocked


216

Element or Attribute Data Type Description message for the associated resource.

type (LockExpired, OperatorUnlocked)

Specifies the reason the resource was unlocked.

day Date Specifies the day of the interval ending in which the URD lockout will end.





9.28.49.29.4 Example The following example shows two URDResourceUnlocked. The first is an example of an expired lock. The second is an example of a manual unlock message. The SOAP wrapping XML is not shown in this example nor is the root element which may be different depending on whether this is received as a notification or a query response. <URDResourceUnlocked type="LockExpired" day="2005-03-10" interval="1000"> <Resource>GEN1</Resource> <ResourceType>GEN</ResourceType> </URDResourceUnlocked> <URDResourceUnlocked type="OperatorUnlocked" day="2005-03-10" interval="1000"> <Resource>GEN2</Resource> <ResourceType>GEN</ResourceType> </URDResourceUnlocked>


217

9.299.30 ViolationRelaxationLimit

9.29.19.30.1 Description The ViolationRelaxationLimit (VRL) message is sent to indicate that a limit was relaxed during the solution of a real-time balaning (RTB) interval. The message indicates the day, interval and limit-bound entity as well as the absolute value of the limit violation amount.

The following types of limit may be relaxed: • Operational Constraint (constraint-related) • Ramp Rate (resource-related) • Capacity (resource-related) • Load/Gen Balancing (system-related) The same message is used to communicate all VRLs, but the content of the message may differ in structure based on the type of the VRL as each type has different data associated with it. Summary

• Resource-related VRLs are participant private data.

• Constraint-related and system-related VRLs are public data.




9.29.29.30.2 Schema Template <ViolationRelaxationLimit violationRelaxationLimitType="sss" day="yyyy-mm-dd" interval="hhmm" [isDuplicateHour="true"]> <OperationalConstraintViolationLimit> <ConstraintName>sss</ConstraintName> <ConstraintType>sss</ConstraintType> <ViolationMW>ddd</ViolationMW> </OperationalConstraintViolationLimit> </ViolationRelaxationLimit> <ViolationRelaxationLimit violationRelaxationLimitType="sss" day="yyyy-mm-dd" interval="hhmm" [isDuplicateHour="true"]> <RampRateViolationLimit> <RampRateLimitType>sss</RampRateLimitType> <ResourceName>sss</ResourceName> <ResourceType>sss</ResourceType> <ViolationMW>ddd</ViolationMW> </RampRateViolationLimit> </ViolationRelaxationLimit>


218

<ViolationRelaxationLimit violationRelaxationLimitType="sss" day="yyyy-mm-dd" interval="hhmm" [isDuplicateHour="true"]> <CapacityViolationLimit> <CapacityLimitType>sss</CapacityLimitType> <ResourceName>sss</ResourceName> <ResourceType>sss</ResourceType> <ViolationMW>ddd</ViolationMW> </CapacityViolationLimit> </ViolationRelaxationLimit> <ViolationRelaxationLimit violationRelaxationLimitType="sss" day="yyyy-mm-dd" interval="hhmm" [isDuplicateHour="true"]> <LoadGenBalanceLimit> <LoadGenBalanceLimitType>sss</LoadGenBalanceLimitType> <ViolationMW>ddd</ViolationMW> </LoadGenBalanceLimit> </ViolationRelaxationLimit>


<ViolationRelaxationLimit>

Complex Type Specifies the ViolationRelaxationLimit message for the associated day, interval and entity if applicable.

violationRelaxationLimitType

(OperationalConstraint, RampRate, Capacity, LoadGenBalance)

Specifies the type of the VRL.

day Date Specifies the day of the interval ending in which the URD lockout will end.



<OperationalConstraintViolationLimit>

Complex Type The encapsulating element for the OperationalConstraint type VRL. This element will only appear if the value of the violationRelaxationLimitType


219

Element or Attribute Data Type Description attribute is ‘OperationalConstraint’

<ConstraintType> Constraint Type Specifies the type of constraint <ConstraintName> Constraint Name Specifies the name of the

constraint <ViolationMW> Absolute MW Specifies the absolute value of

the limit violation amount. <RampRateViolationLim

it> Complex Type The encapsulating element for

the RampRate type VRL. This element will only appear if the value of the violationRelaxationLimitType attribute is ‘RampRate’

<RampRateLimitType> (Up, Down) Specifies the direction of the violation.

<ResourceType> Resource Type Specifies the type of resource <ResourceName> Resource Name Specifies the name of the

resource <ViolationMW> Absolute MW Specifies the absolute value of

the limit violation amount. <CapacityViolationLim

it> Complex Type The encapsulating element for

the Capacity type VRL. This element will only appear if the value of the violationRelaxationLimitType attribute is ‘Capacity’

<CapacityLimitType> (Up, Down) Specifies the direction of the violation.

<ResourceType> Resource Type Specifies the type of resource <ResourceName> Resource Name Specifies the name of the

resource <ViolationMW> Absolute MW Specifies the absolute value of

the limit violation amount. <LoadGenBalanceViolat

ionLimit> Complex Type The encapsulating element for

the LoadGenBalance type VRL. This element will only appear if the value of the violationRelaxationLimitType attribute is ‘LoadGenBalance’

<LoadGenBalanceLimitType>

(Deficit, Excess) Specifies the direction of the violation.


220

Element or Attribute Data Type Description <ViolationMW> Absolute MW Specifies the absolute value of

the limit violation amount.

9.29.49.30.4 Example The following example shows an instance of each type of VRL. Note that the element describing the VRL is different for each type, and that only one of the type-specific elements may appear in a given instance of a ViolationRelaxationLimit message. <ViolationRelaxationLimit violationRelaxationLimitType="OperationalConstraint" day="2010-07-28" interval="15”> <OperationalConstraintViolationLimit> <ConstraintName>OC1</ConstraintName> <ConstraintType>Flowgate</ConstraintType> <ViolationMW>15</ViolationMW> </OperationalConstraintViolationLimit> </ViolationRelaxationLimit> <ViolationRelaxationLimit violationRelaxationLimitType="RampRate" day="2010-07-28" interval="15"> <RampRateViolationLimit> <RampRateLimitType>Up</RampRateLimitType> <ResourceName>UNIT1</ResourceName> <ResourceType>GEN</ResourceType> <ViolationMW>15</ViolationMW> </RampRateViolationLimit> </ViolationRelaxationLimit> <ViolationRelaxationLimit violationRelaxationLimitType="Capacity" day="2010-07-28" interval="hhmm"> <CapacityViolationLimit> <CapacityLimitType>Up</CapacityLimitType> <ResourceName>UNIT1</ResourceName> <ResourceType>GEN</ResourceType> <ViolationMW>15</ViolationMW> </CapacityViolationLimit> </ViolationRelaxationLimit> <ViolationRelaxationLimit violationRelaxationLimitType="LoadGenBalance" day="2010-07-28" interval="hhmm"> <LoadGenBalanceLimit> <LoadGenBalanceLimitType>Deficit</LoadGenBalanceLimitType> <ViolationMW>15</ViolationMW> </LoadGenBalanceLimit> </ViolationRelaxationLimit>

SPP External Interface Specification Market Participant XML 36 - mui xml interface... · 9 2.1...

Documents

Transcript of SPP External Interface Specification Market Participant XML 36 - mui xml interface... · 9 2.1...