|
|
|
Parent Menu
Same Level Menu
Child Menu
Questions/Comments
|
Customer Services - Overview of Real Time Pricing (RTP) FunctionContentsList of RTP Subfunctions
NarrativeRTP ObjectiveThe objective of the Real-Time Pricing Enterprise Activity is to permit customers to plan and modify their load and generation in response to price signals in “real-time” (operational timeframe which can range from seconds to days ahead), received from an Energy Services Provider who acts as an intermediary to the Market Operations. Customers can also provide their forecasted loads and generation into the Market Operations (possibly through the ESP as an aggregator) as energy schedules and ancillary bids/offers. For operators of the power distribution system, Real-Time Pricing provides a mechanism for potentially significant changes in aggregated load based on sharing cost drivers with the customer in an elective supervisory control scheme. RTP Day-in-the-Life ScenarioA typical day-in-the-life scenario is as follows (note that the discussion is marked up with numbers that are used later in the analysis to derive requirements from the scenario): In the historical energy supply system, the time-based analysis of customer consumption of energy was cost prohibitive. Yet, the actual cost of providing energy is substantially time and load dependent. The regulated utility was the great averaging factor for these variable costs. Today, modern electronics and communications make it cost effective to apply a more accurate allocation of costs and usages of energy. Real-time pricing is a market mechanism to provide for dynamic feedback control and pricing of energy based on genuine costs. (1)Periodically, the RTO/ISO market operations system (or other market entity, depending upon the market design) forecasts power system conditions for a specific period, say the next 24 hours, based on energy schedules and prices already submitted, ancillary services available, weather conditions, day of the week, scheduled outage information from transmission and distribution operations, and real-time information from transmission and distribution operations, etc. (2)From these forecasts, an RTP Calculation function develops tables of load versus price for each “power system node” and for each “settlement” period (e.g. each hour). These tables are the Base RTP data. The purpose of this computation is to accurately forecast the cost of providing energy during the period. (3)These Base RTP tables are made available to all subscribers of this information (depending upon market rules), typically by being uploaded to a Market Interface Server. (4)The Energy Services Provider (ESP) obtains the Base RTP data tables from the Market Interface Server, and uses them to develop Customer-specific RTP rate tables. These calculations are based on contractual agreements between the ESP and the different types of customers it serves. For example, a large industrial customer that can curtail large loads during peak hours will get a different rate than a small commercial customer with less ability to modify its load. (5)The ESP sends these Customer-specific RTP rate tables to each of the customers it serves, using different mechanisms: fax, email, or direct data channels (e.g. dial-up telephone or AMR system). (6)The customer’s Building Automation System (BAS) optimizes its loads and distributed energy resources (DER), based on the customer-specific rate table it receives, the load requirements and constraints, and any DER requirements, capabilities, and constraints. The BAS understands the nature and opportunity for altering consumption based on economic and comfort drivers, and, the physical dynamics of the specific customer premises. (7)The BAS then issues (or updates existing) schedules and other control mechanisms for loads and for DER generation. These control actions may be automatically implemented or may be reviewed and changed by the customer. (8)The Customer’s BAS may then send generation schedules to the DER management system for it to implement during each “settlement” period. (9)The BAS system uses the site-optimized algorithms to forecast its load and DER generation. It also determines what additional ancillary services it could offer, such as increased DER generation or emergency load reduction, and calculates what bid prices to offer these ancillary services at. (10)The BAS then submits these energy schedules and ancillary services bids to the ESP (or Scheduling Coordinator, depending upon market structure), as input to the RTO/ISO market operations. (11)The ESP aggregates (or leaves as individual information) the energy schedules and ancillary service bids, and submits them to the market operations. These will affect the next iteration of RTP calculations. (12)As each “settlement” period is reached or during each period as optimal, the BAS issues load control commands to the end devices (setting levels, cycling, turning on/off, etc.). The DER management system controls the DER devices according to the DER schedule. (13)The distribution operations systems monitor any larger DER devices to ensure power quality constraints are met, and to help manage emergency situations (detailed in the Advanced Distribution Automation Use Case). (14)Load and generation deviations, as well as initiation of ancillary services which have been requested by the market operations, are handled according to normal market operations procedures (as detailed in the Market Operations Use Case). (15)In the post “settlement” period (as shown in the Meter Reading Use Case), customer load and generation meters are read by Meter Data Management Agents (MDMAs) and passed to the market operations settlement systems (as shown in the Market Operations Use Case). {Not shown in the RTP Work Flow drawing} The availability of fine-grained load profile information (for example, measurements integrated for each 15 minute period of consumption during the billing period), allows for accurate application of the agreed upon tariff. (16)External regulators and auditors review the RTP base and customer-specific tables to ensure compliance with market rules.
Steps
|
|
IntelliGrid Architecture
|