Garland Power & Light
ERCOT Nodal Market Operations System
Request For Information
The purpose of this document is to provide:
 An overview of the requirements for a Market Operations System (MOS) Function that
Garland Power & Light will use to conduct business in the ERCOT Nodal Market.
 A Request For Information (RFI) about vendor standard product compliance, infrastructure
requirements, documentation, etc.
This system will provide GP&L both an automated machine to machine interface as well as an
interface for GP&L personnel to perform all functions as outlined in the Texas Nodal Enterprise
Integration External Interfaces Specification v 0.92 (Attachment A). Any conflicts between
Attachment A and this document concerning communication methods, standards, or message
information, Attachment A takes precedence. ICCP communications are not in the scope of this
system or document.
The Market Operations System functions for GP&L include:
 Communications between the GP&L Market Operations System and the ERCOT Nodal Market
System. Communications must comply with standards, specifications, and security measures as
set forth in the Texas Nodal Enterprise Integration External Interfaces Specification v 0.92
(Attachment A).
o Standards include
 Security & Web Services as defined by W3C and OASIS
 IEC Common Information Model (IEC 61970-301)
 IEC 61968-1 for message structures
 OASIS WS-Base Notifications standard
 ISO-8601 timestamp definition of the exception of 24:00:00
o Web Services are defined by a combination of Web Services Definition Language
(WSDL) and XML Schemas
o Payloads typically conform to a defined XML schema. Exceptions are
 RDF files
 Dynamic query results
 CSV formats
 Excel spreadsheet
 PDF files
 Compressed files (based on size or one of above formats)
 Market Message Processing Functions
o System must be able to create in the proper format, submit, update, query, cancel,
receive and interpret all message types & individual messages as specified in the Texas
Nodal Enterprise Integration External Interfaces Specification v 0.92 (Attachment A).
 Market User Business Functions
o System must provide user interfaces that provide the user forms (displays) for the
development of all message types / requests / queries originating from GP&L and forms
for reading all notifications, alerts, submission errors, message types & messages
originating from ERCOT





Interface must translate the information into or from the required ERCOT format
for both receiving & submitting all message types as specified by the Texas
Nodal Enterprise Integration External Interfaces Specification v 0.92
(Attachment A).
 Interface must package various messages / transactions together (as in a “bidset”)
as defined in the Texas Nodal Enterprise Integration External Interfaces
Specification v 0.92 (Attachment A).
 Interface must perform standard XML Schema error checking before sending
message to ERCOT
o There must be a “workspace” for developing / updating / canceling / storing all types of
transactions (energy offers / bids, A/S offers / bids, 3 part offers curves, inc / dec curves,
etc.) without actually submitting the curves
 User shall have the ability to display the curve data in a graphical format for
analysis / sanity check
 System will have a submit to ERCOT “yes / no” selection for each transaction
o System must provide Ancillary Service calculations & displays as outlined in the Nodal
Specifications for AS Summaries (attachment B)
o There must be tools for netting transactions (awards, trades, etc.) per interval for the Day
Ahead Market (DAM) & the Real Time Market (RTM)
o Interfaces must be user friendly
Market Operations Scheduling System must have the capability of creating schedule profiles
(scheduled net interchange) for use by an Open Systems International, Inc. (OSI) EMS system.
o System must provide user interfaces that provide the user forms (displays) for
developing, recording & storing bilateral transactions / schedules and energy trades.
 These bilateral transactions / schedules / energy trades, some of which may or
may not be submitted to ERCOT
 System must provide a way for the these transactions to be “accepted” (even
though they are not sent to ERCOT), be saved in the databases and be included in
any calculations
o System must provide means to be able to develop ramping schedules (as example – ramp
from 5 minutes before the hour and completing the ramp 5 minutes after the hour)
Market Operations System must be able to handle all expressed functions / functionality for the
Garland Power & Light QSE and those same functions and functionality for multiple Sub QSEs.
This system must support the expansion (new contracts) or shrinking (expiring contracts) in size
as contracts are made to provide QSE services for other entities.
Market Operations System Users
o System must support a minimum of 12 concurrent GUI users
o If a machine to machine (application to application) connection to another GP&L system
(i.e. automated data query) is considered a “user”, then these machine connections are
not to be considered as part of the 12 concurrent GUI users referred to above.
Market Operations System Security - At a minimum, security features MUST comply with
NERC’s Cyber Security Critical Infrastructure Protection (CIP) Standards 1 – 9 (Attachment C
– Zip file containing CIP Standards 1-9)
o Among other requirements, CIP Standard 7 specifically deals with
 Ports & Services
 Security Patch Management









 Malicious Software Prevention
 Account Management
 Passwords
o Among other requirements, CIP Standard 5 specifically deals with Access (remote or inhouse) and Appropriate Use Banner
Market Operations System to EMS Interface and Settlement System Interfaces. The Market
Operations System shall have an open, non proprietary database structure so that the GP&L
EMS applications and Settlement System applications can be written to query data from the
MOS. This data could include:
o Net transactions (sales, purchase, bilateral trades, etc) for EMS broken down into 15
minute intervals
o Ancillary Service Obligations – all types per resource
o Non-Spin Deployments
o LMPs, SPPs and MCPCs
o CRR details
Market Operations System must provide appropriate alarm messages for communication issues
with ERCOT ISO, data archive, and alarm messages for issues for all business functions.
Alarms should provide specific information that will assist in troubleshooting issues –
something more than just “function failed”
Market Operations System Database Capabilities
o The Online Interactive Database must provide a online database storing 2 years of data
o The Archive Interactive Database must provide a database storage for a period of 5 years
(that is in addition to the 2 years
o All messages sent to or received from ERCOT, bilateral transaction, etc. must be
recorded / stored in the database/file storage areas. Data is to be kept for 7 years: 2 in
the on-line system and 5 in the archive system.
o Dropping tables must be configurable for manual or automatic dropping after specified
data storage time has been reached
Market Operations System must provide a feature or application to populate COP
o These parameters have hourly values for the “rest of today” plus 7 days
o This time period is a rolling time period
Market Operations System must have reporting capability with features enabling users to create
custom reports
Market Operations System must be licensed and structured in a way that will allow GPL staff to
augment (create, modify, test, etc) GUI displays
Test Capabilities
o System shall have the ability to build test messages (all types) and inject those messages
into the system for processing to simulate receiving them from ERCOT for test
purposes.
o Any test messages must be “harmless” to the system – no actions initiated, no settlement
issues created, no EMS control deployments actually initiated.
Market Operations System must be deployed on Windows operating system.
Market Operations System Configuration
o The vendor will provide complete working systems including servers, application
software and any third party software such as Relational Data Bases. The hardware will
include provisions for the on-line systems and the archive systems.






o Production Market Operations System shall consist of
 Primary application & database running on a server
 Backup (complete, full instance of primary) application & database running on a
redundant server
o Test Market Operations System Application & database running on a test server
o Non-Redundant Market Operations System Application & Database running with an
EMS at a Backup Center in a remote location
Production Market Operations System Redundancy
o The System must be fully redundant with automatic failover. The MOS failover shall
not require failover of EMS servers.
o Primary & Backup applications & databases must employ some type of “watchdog” so
that in case of a primary application or database stall or server failure on which the
primary is running, the backup application & database will take over all functions
Market Operations System operation
o Must be designed to operate 24 X 7
o Must be designed to provide availability of 99.9%
Market Operations System must be Daylight Savings Time compliant in accordance to the
ERCOT standard / definition. The dates for Daylight Savings Time transitions must be
configurable – Congress may change the dates again.
Market Operations System software must be configurable by GP&L personnel. The software
cannot be a “black box” where GP&L personnel cannot maintain the system or make changes.
Market Operations System Start Up and Acceptance Testing
o There will be 168 hour test without failure as part of the site acceptance test but this will
not be performed until FULL Nodal functionality testing with ERCOT has been
completed.
o The services of a Support Engineer will be needed on site.
 During installation / checkout
 Concurrent with Market Go Live
o Latest comments from ERCOT call for the system to be installed, functioning, and
qualified in the Nodal Sandbox no later than October 1st, 2007
Market Operations System Warranty – The system (hardware and software) shall be warranted
for a period of 1 year after the last milestone is satisfactorily met. Any defects there are not due
to an ERCOT change will be repaired at no cost under the warranty.
The Texas Nodal Enterprise Integration External Interfaces Specification v 0.92 (Attachment A)
includes at least the following message groups & messages
 Market Transaction Service Interfaces
o Required to Create (Submit), Get (Query), & Cancel (Withdraw) offers, bids, trades,
offers, schedules, plans, etc.
o Payloads that would otherwise exceed 1 megabyte should be zipped, base64 encoded
and stored within the “Payload / Compressed” tag
o Message Types are:
 Three Part Offer
 Self Arranged Ancillary Services
 Incremental / Decremental Offers
 Ancillary Services Offer


 Ancillary Services Trade
 Capacity Trade
 Congestion Revenue Rights (CRR)
 Current Operating Plan (COP)
 DC Tie Schedule
 Energy Bid
 Energy Only Offer
 Energy Trade
 Output Schedule
 PTP Obligation
 Self Schedule
Market Information Interfaces
o Provides functions to request information from ERCOT
o Types are
 Get Award Set (queries various awards)
 Forecasted Load
 Real-time System Load
 Market Totals (DAM Energy bought & sold, A/S offers)
 Market LMPs & SPPs
 Market MCPCs
 Binding Constraints
 Active Contingencies in SCED
 Ancillary Service Schedule Obligations
 Dynamic Ratings
 Voltage Profiles
 Total Regulation
 Load Ratio Share
 Competitive Constraints
 Load Distribution Factors
 Shift Factors
 Customer Load Profile
 Aggregated Ancillary Service Offer Curves
 Ancillary Service System Plan
 Unit Availability
 Startup & Shutdown Instructions
 Total Ancillary Service Offers
 Total DAM Energy
 Derated CRRs
 Proxy Curves
 Mitigated Curves
Notification Interfaces
o Types are
 Notices & Alerts
 Bid Set Acceptance
 Bid Set Errors
 Pending Trade



 Energy Offer Awards
 Energy Only Offer Awards
 Energy Bid Awards
 Ancillary Service Awards
 CRR Awards
 PTP Obligation Awards
 Outage Notifications
Acknowledgement of Alerts
o Single type to acknowledgement receipt of Alerts
Interface to the NMMS Outage Scheduler Message types include:
o Creation
o Query
o Cancellation
Utility Interfaces Message types include:
o Get mRID (transaction ID)
o System Status (connection check)
The following information shall be provided with the response to this RFI.
 Description of the company that is responding to the RFI.
 Description of the standard product that would be bid in response to the specification above.
 A list of requirements in the specification above with which the standard offering does not
comply.
 List of documentation that would be provided with system – as a minimum the following would
be included
o Users Guide
o Configuration Guide
 Typical system hardware drawing with equipment sizing and model numbers.
 List of training courses available for this product. Highlight any that are NERC certified
courses.
 Provide a list of the following:
o Hardware platforms supported
o Software platforms supported
o Relational Databases supported
o 3rd party software utilized
 A list of installations the responding company has in service where the installation is the real
time Market Participant to ISO application
Attachments:
 Attachment A
o Texas Nodal Enterprise Integration External Interfaces Specification v 0.92
 Attachment B
o Nodal Specifications For AS Summaries
 Attachment C
o Zip File Containing NERC Cyber Security Critical Infrastructure Protection (CIP)
Standards 1 – 9