Web Based Energy Scheduling

(1)

POWER SYSTEM OPERATION CORPORATION LIMITED

Western Regional Load Dispatch Centre

F-3, MIDC Area, Marol, Andheri (E)-Mumbai-400093

Technical Specification (TS)

For

Web Based Energy Scheduling

In

Regional Load Dispatch Centres

and

(2)

1

Indian electricity grid has been demarcated into five distinct electrical regional grids viz. Eastern, Northern, North-Eastern, Southern and Western regional grids. Each regional grid is managed by an independent Regional Load Dispatch Center (RLDC) which is an Apex body to ensure integrated operation of power system in the respective region. National Load Dispatch Center (NLDC) coordinates the operation of all regional grids on matters related to inter-regional exchange of power within the country and trans-national exchanges involving India. Presently all the regional grids except Southern regional grid are operated synchronously as N-E-W Grid. The exchange of power amongst the synchronously connected regions takes place through 765/400/220KV transmission lines and HVDC interconnections whereas the power exchange with Southern region is through HVDC interconnections only. Each RLDC carry out the task of real time operation of respective grid (System Operation Function) in association with State Load Dispatch Centers (SLDCs), Inter-State Generating Stations (ISGSs), Independent Power Producers and other players operating in the region and also coordinate with other RLDCs and NLDC for inter-regional exchanges. In addition to real time operation, RLDCs have to carry out other offline pre-dispatch and post-dispatch functions in coordination with its associates. Offline activities includes scheduling and other Market Operation Functions such as approval of short term open access, metering and settlement, administration of ABT pool account, reporting & analysis.

Commensurate with economic development, Indian Electricity Grid is expanding exponentially with increased number of interconnections between Regions and increased power flow across the regions. Apart from the Inter-regional connectivity, a large number of IPPs and UMPPs are coming up along with associated 765 / 400KV interconnections within and across the region rendering power system operation more and more complex. Above all with the implementation of open access market and Power Exchange, the contracts are to be implemented by the system operators which demand that the existing lines / corridors are to be loaded to their limits. It becomes onerous responsibility for the system operators to meet the market requirements and at the same time maintaining grid security and safety and to satisfy the consumer aspiration for quality and reliable power supply. Hence power system operator needs to be provided with the necessary tools to meet such complex, multi-dimensional requirements of ever increasing demands of the customers while complying with the regulatory requirements. The overall impact is achieving newer dimension in power flow quantum and direction through implementing proper functions and tools like Energy Scheduling.

1.2 Existing Scheduling Practice

According to India Electricity Grid Code (IEGC) energy scheduling is a daily sequence of time bound activities commencing with submission of availability by the generators at 08:00 AM each day for the forth coming day. RLDCs have overall responsibility for optimum scheduling and dispatch of electricity within the region involving ISGS / IR / IPP / Beneficiaries. Further RLDCs have to undertake real time schedule revisions on the day of operation for the respective constituents. The present practice of energy scheduling for day ahead and day of

(6)

5

operation is carried out in different RLDC using different approaches and platforms (for instance in NRLDC, SRLDC and WRLDC scheduling is done through web-enabled, database – Oracle/Foxpro oriented VB/.NET utility developed in house while in NERLDC and ERLDC scheduling is done through MS-Excel).

The existing scheduling utility available at all RLDCs broadly involves the following functional modules:

i. Data input from Users – Declared capacity, Requisition, STOA, etc.

ii. Data output – Injection, Drawal, Inter-Regional Schedule and URS available at ISGS

iii. Open Access Input – C-DAC OA s/w (CSV file); manual entry iv. Power Exchange Input – Through NLDC (CSV file); FTP

v. Scheduling Preparation – In line with IEGC

vi. Data output for SCADA – SCADA display in Control Room; Text file vii. Data output for RPC – Offline text file

viii. Data output for PSP – CSV file

ix. Schedule publishing – Dynamic ASP pages on RLDC web-site x. Other reports – CSV /DOCX file for MIS/meetings

1.3 Purpose of this Document

The intent of this document is to facilitate implementation of a uniform approach towards energy scheduling through a common software solution. This document provides desired architecture, functional and performance requirements of a web-enabled energy scheduling application software. The software will be deployed in all the RLDCs and NLDC with minor customization of business rules for effecting energy scheduling in the respective regions. In addition to scheduling roles and responsibilities of NLDC stipulated in IEGC, NLDC shall function as a backup of RLDC(s) as a part of disaster management system. In view of this, the application software to be installed at NLDC is also intended for replicating the scheduling activity of any RLDC(s) if the need arises.

1.4 System Architecture

This section describes the overall system architecture (Annexure-I) of the web-enabled energy scheduling application software to be deployed in all RLDCs and NLDC.

The scheduling software shall reduce the diversity in approach towards daily energy scheduling across the RLDCs and NLDC. It is proposed to implement database oriented software with modular structure and provide web access to the users through appropriate authentication for exchange of energy scheduling related data.

(7)

6

The software shall be based on layered architecture having separate and distinct layer for presentation, business logic and database. Industry standard web services shall be used for exchange of data between two systems e.g. between different software systems. All user interfaces shall be web based following W3C standard and shall be compatible with all major browsers like Internet Explorer, Firefox, Chrome, Safari etc. No numerical value or configurable parameters shall be hardcoded in the software. For entry of all such inputs, separate forms shall be provided. All calculations are guided by IEGC, other rules / regulations issued by suitable agency / commission and may change from time to time.

1.4.1 Hardware Section

Hardware supply and the activities mentioned herein shall be in user scope, i.e., respective RLDCs/NLDC as specified in Section 1.6.2. However, system sizing, configuration, inter process communication (IPC), security and other related issues shall require vendor coordination.

i) Web Server and Database Server

Web servers and database servers shall be installed at RLDCs and NLDC whereas users are located at their respective locations covering whole country. Web based Energy Scheduling Application Server with Database Server shall be used for storing time-series Energy Scheduling data along with configuration parameters for future use in standard format e.g. SQL compatible database. Database, in the scope of the bidder, shall be provided with full data storage of the Energy Scheduling for the entire life cycle of the Scheduling software. Retrieval of data from the Server should be possible by querying with SQL-99 compliant SQL query language. The number of data server shall be as per BOQ mentioned in Section 2.12.

ii) Workstation

Workstation will be provided to operators at RLDCs and NLDC for using the application. Routers, Switches, Firewall etc shall be installed at respective RLDCs and NLDC premises to provide secured access of the application software. SLDCs, Generating Stations, IPPs, Traders & other users shall, upon prior authentication, have role based access to the application through any standard browser installed in their respective existing workstations. The application software shall be designed accordingly.

iii) Printers

Colour Laser printer shall be used to take hardcopy printout and shall be interfaced with Ethernet LAN either directly or through individual print server. Application software shall be capable for printing various reports, graphs, outputs, etc on A4 & A3 size normal paper.

iv) Communication

Establishment of TCP/IP communication among all equipments (i.e, web servers, data servers, printer, etc) will be done at the user end. Necessary coordination with different

(8)

7

machines / servers / database / printer and proper handshaking amongst the systems installed during implementation of the software are considered to be in the scope of this project.

v) Cyber Security

Proper external cyber security will be provided by RLDC/NLDC. However the vendor should specify the ports and services required to be configured on firewalls for the application to be available for external users.

1.4.2 Software Section

i) Operating System

Operating System for the servers, database, user workstations with browsers (IE 7 or latest version) for smooth user operation of the Web based Application shall be provided by user. However any other user level software requirement for operation of the application shall be provided by the vendor.

ii) Client

Browser based clients either in Microsoft Windows or Linux Environment using Internet Explorer / Mozilla/ Chrome etc will be provided. However the application usage should be browser independent for same look and feel on different browsers.

1.5 General requirement

In view of implementation of the application software at multiple locations, it is intended that the project shall be executed through open tender evaluated jointly followed by composite LOA for all locations - RLDCs / NLDC (total 6 nos) on the successful bidder. Vendors are encouraged to visit the locations at their own cost for proper assessment of the project requirements prior to bid submission.

The Software Implementer (SI) shall be the primary bidder and shall take single-point responsibility of contract. All qualifying requirements shall be met by a single company/firm. SI shall meet the following qualifying requirements:

1. The primary business of the bidder should be Software development and implementation and should be a registered company under the companies act in India and should be in this business for more than 5 years.

2. The product should be built on open standards without use of any proprietary technology specifically designed for any user requirement. Bidder shall deliver required product with all functionalities as per technical specification using standard open platform provided by OEM which has capability to handle and manipulate time series

(9)

8

energy data. The platform shall be supported by OEM through structured training program and product support system.

3. (a) The bidder should be a company with ISO9001 certification. The bidder must have supplied ABT based scheduling solution to at least one state-level utility in India. The same should be running successfully at any Central / State Govt. / Govt. undertaking for at least 6 (six) months on the day of bid submission. The bidder shall organize inspection for such sites if RLDC (POSOCO) desires so. The bidder should have a minimum turnover of at least ` 5 Crores in last audited financial year.

OR

(b) The bidder should be a software company with at least CMMI Level-5 certification. The bidder should have successfully implemented projects involving web-interface along with RDBMS as backend and should have a turnover of more than ` 5 Crores in last 3 (three) audited financial year.

OR

(c) The bidder should be Software Company with at least CMMI Level-5 certification. The bidder should have successfully executed software projects and should have a turnover of ` 50 Crores in last audited financial year.

1.6 Scope of Work

This section provides details of work included in the bidders scope, work excluded from the bidder’s scope, facilities to be arranged by bidder and facilities to be provided by POSOCO. 1.6.1 Bidder’s Scope of Work

The scope of work covers all 6 (six) locations, viz., ERLDC – Kolkata, NERLDC – Shillong, NRLDC – Delhi, SRLDC – Bangalore, WRLDC – Mumbai and NLDC – Delhi and includes complete conformity with subsequent sections of this document and shall include planning, design, development, integration, testing, supply, installation, training, commissioning, demonstration for acceptance and documentation of the complete web-enabled energy scheduling software solution. The proposed hardware architecture is shown in Annexure-I. The scope also includes one year warranty and three years maintenance of the software with provision for 1 year (optional) extended maintenance as mentioned in Section 5.1.

The following shall be under Bidder’s scope:

i. Design Document for complete web-enabled energy scheduling software solution. ii. Software Requirements Specifications for web-enabled energy scheduling software

solution.

(10)

9

iv. Coordination with different machines / servers / database and proper handshaking amongst the systems installed.

v. Database development, Displays and Reports. vi. Normalized structure of database.

vii. Secured high availability of application software. viii. Training of POSOCO personnel

ix. Warranty for one year after issue of OAC by respective RLDCs/NLDC.

x. Support for XML data exchanges. CIM support for data exchange is encouraged as an additional feature against clause 2.5.9(iii), 2.5.10(iv), 2.5.12(iv), 2.8.1, 2.8.2 and 2.8.3 of this document but not essential for project implementation.

xi. Support and Maintenance during 3 + 1 (optional) years extended period after expiry of warranty period inclusive of modifications due to regulatory issues/orders. Any other work which is not identified here or in the specification but is required for completion of the project within the intent of this specification shall also be in the scope of the Bidder without any extra cost to POSOCO.

1.6.2 Exclusion from Bidder’s Scope

i. All Hardware as mentioned in Section 1.4.1

ii. Environment (OS, DBMS, etc) as mentioned in 1.4.2

iii. All necessary permission / clearances for installation, testing, commissioning of the Energy Scheduling software

1.6.3 Facilities to be provided by RLDCs/NLDC for Project Implementation

RLDCs and NLDC will provide following facilities as may be reasonably required for project implementation:

i. All hardware and software (OS) as indicated in Section 1.6.2 including MS office and antivirus software. However, bidder shall be responsible for all integration work required in this regard for successful deployment of the solution at user premises. ii. Providing power supply outlets for site development/configuration of bidder

equipment, if any.

iii. Providing storage space at sites wherever available.

iv. All permission at site for carrying out installation, testing & commissioning, training, etc.

(11)

10

1.7 Implementation Outline of Scheduling Software

It is intended to implement a database oriented web-enabled software solution to enable energy scheduling. The software will be capable to carry out day ahead scheduling as well as real time schedule revision on day of operation in accordance to IEGC and regulations and orders issued by Central Electricity Regulatory Commission (CERC). The application packages / modules envisaged in the software to carry out energy scheduling effectively are given below:

i. Energy Scheduling –

Web based energy scheduling software module enabling users to submit Declared Capacity (DC) and requisition; publish / view / download dispatch and drawal schedules with provisions for revision on day ahead and real time basis. Implementation of POC Transmission Losses in accordance with CERC (Sharing of Inter State Transmission Charges and Losses) Regulations, 2010, amended from time to time is an inherent part of the scheduling process and shall be through a POC Transmission Losses module.

Scheduling is a timeline activity and any Post-facto correction of schedules shall be permitted by system administrator to limited supervisory users through additional password configuration. These corrections/modifications shall be logged and archived appropriately to identify, report and scrutinize such cases at a later date. ii. User Management –

Role based user management system shall be adopted to configure different user comprising of State, DISCOM, ISGS, embedded entities, multiple status entities (same entity in more than one zone), Traders etc. There would be provision for user profile having varying attributes.

iii. Data Storage –

All data base activity including archiving should be based on relational database. iv. Reporting –

There are multiple data output requirements involving raw and process information in a comprehensive manner.

v. User Interface –

User interfaces and views are required for different categories of users say for data entry, data viewing, etc. It is proposed to provide role based access to the user so that data pertaining to specific user only are accessible.

vi. Security –

Role based user management system and user authentication at multiple level shall be in place for secure access. Proper user login, logout rules shall be implemented. Software should maintain all user activities in a separate database under respective user’s login name.

(12)

11

vii. Log in Time out –

There would be provision for warning and log in time out as per administrator configuration.

viii. Reliability –

There would be provision for high level of reliability in application and database with alarm exit, time out exit, etc.

It is intended to complete this project within the time frame mentioned in Annexure-II with indicated standard hardware and operating system software in line with overall requirement of this specification. The system should be suitably scalable to integrate additional functions / devices with matching open source depending upon the usage pattern of the supplied system. Also it is to be mentioned that the software is meant for 24 x 7 operations involving Indian power system operation which is a critical infrastructure. Thus proven and high level of availability of the software is essential and criticality of the application should be considered by bidder to design and provide appropriate software for satisfactory and continuous operation in India.

1.8 Project Implementation Plan

The project shall be implemented within 6 (Six) months (26 weeks) from the date of award as attached at Annexure-II. There would be a software availability test of 7 days within the commissioning period as mentioned in Annexure-II on implementation schedule. Successful bidder would ensure required availability referred on item 5.5 of this document. The bidder shall provide a detailed project implementation plan and schedule that is consistent with implementation plan mentioned in Technical Specification along with the bid. The implementation plan shall include the activities of both bidder and RLDCs/NLDC showing key milestones and clearly identifying the nature of all information and support expected from RLDCs/NLDC.

(13)

12

SECTION – 2

Web Based Energy Scheduling Software-Functional Requirements 2.1 General

Scheduling of energy within and across the region is one of the prime functions of load dispatchers in RLDC/NLDC which is to be achieved through a series of timeline activity & data flow between RLDCs /NLDC/Power Exchanges/ beneficiaries / generators as stipulated in IEGC and relevant Orders / Regulation of the Hon’ble Commission (CERC). Scheduling of power essentially involves collecting availability data from generating stations and allocating corresponding shares to constituents/beneficiaries from respective generating stations based on allocations decided by Ministry of Power from time to time. Other collateral subjects that needs to be taken into account while scheduling are Open Access transactions, ATC declaration, Real time revision of schedules by RLDC system operators subject to Power regulations, statutory changes in force and as amended from time to time.

2.2 Energy Scheduling

The scheduling process in the present regime generally called ABT (Availability Based Tariff) regime is in accordance to Indian Electricity Grid Code Regulations 2010 issued by CERC. All input / output like generation availability, requisition from beneficiaries, drawal and dispatch schedules and other associated data and calculations would be done for 15min time block (one day consists of 96 time blocks). All interactions shall require appropriate login by the users.

The output shall be dispatch schedules for generating stations, Inter-state drawal schedules for beneficiaries, Inter-regional tie-line schedules and URS available at ISGS. The output shall clearly indicate Long Term Access (LTA), Medium Term Open Access (MTOA), Short Term Open Access (STOA) including Bilateral Transactions and Collective Transactions along with all relevant transaction details. Bilateral transactions shall require data integration with existing web-enabled STOA software while details regarding Collective transactions presently channeled through NLDC as an offline sequence of activities shall be automated.

All schedules for implementation shall be affected through appropriate approval by authenticated users at RLDC/NLDC level. The proposed software shall be capable to affect day ahead scheduling and subsequent schedule revisions as per the provisions of IEGC 2010 within stipulated time line. Revisions can be on account of generators (revised availability, unit tripping, etc), beneficiaries (revised requisitions, load crash, surrender of power, etc) or suo moto by RLDCs/NLDC (optimum scheduling, contingency, etc). Once request for schedule revision is received from any user, the program shall recalculate the schedules and the revised schedule shall be updated at all interfaces with a new revision number sequentially generated by system along with the reason for revision. Number of blocks for which the schedules to be revised shall be configurable and indicated in the revision request by users / administrator.

(14)

13

2.3 Scheduling Philosophy

Scheduling is a day-ahead activity and real time revision of schedules is done on the day of operation as per provisions of IEGC and relevant orders and regulations of Hon’ble Commission issued from time to time. For purpose of scheduling, each day (24 Hours) is divided into 96 blocks of 15 minutes duration each.

Eg:- Block01 0000-0015 Block02 0015-0030 .

.

Block96 2345-2400

Chronology of day ahead scheduling activity in time line format is shown below to represent the interaction of various users.

0 8 0 0 IS G S s su b m it a v a ila b ili ty 0 9 0 0 A T C t o N L D C 1 0 0 0 E n ti tl e m e n t to B e n e fi ci a ri e s 1 1 0 0 A T C t o P X b y N L D C 1 3 0 0 1 4 0 0 1 5 0 0 1 6 0 0 1 7 0 0 C o lle ct iv e t ra n sa ct io n r e q u e st to N L D C b y P X s N L D C i n fo rm s co n g e st io n t o P X s P X s g iv e s co n g e st io n r e lie v e d tr a n sa ct io n r e q u e st t o N L D C S L D C s su b m it r e q u is it io n t o R L D C s N L D C f o rw a rd s co lle ct iv e tr a n sa ct io n s to R L D C R L D C c o n fi rm s a cc e p ta n ce t o N L D C 2 2 0 0 S L D C s/ IS G S s in fo rm m o d if ic a ti o n s to R L D C s R L D C i ss u e s R 0 s ch e d u le P X s in fo rm s co lle ct iv e tr a n sa ct io n s to S L D C s re g a 1 8 0 0 N L D C f o rw a rd s a cc e p ta n ce t o P X s 1 7 3 0 R L D C s is su e R 1 s ch e d u le 2 3 0 0

(15)

14

The net drawal schedule of a state would be the sum of following after application of Point of Connection (PoC) transmission losses –

(i) ex-power plant schedules from different ISGS,

(ii) bilateral exchange through Open access procedure in force and (iii) any other transactions

Accordingly, each ISGS will be given a dispatch schedule drawn after summating the following and subject to technical constraints –

(i) requisitions by each beneficiary, restricted to their on-bar entitlements and subjected to system operation restrictions on applicable time blocks, such as, ramp up/ ramp down requirements, technical minimum requirements, power regulations, curtailment on any other account, etc.

(ii) requisition of unrequisitioned surplus capacity (if any),

(iii) bilateral exchange through Open access procedure in force and (iv) any other transaction.

2.4 Project/Product Scope

The proposed web based energy scheduling software shall be modular, menu based web enabled application. All user interaction shall be through appropriate interfaces after due authentication only. The application shall manage all data using Oracle RDBMS. Apart from facilitating a uniform approach to scheduling activity, web based scheduling software shall encourage transparent participation from stakeholders through a structured and user friendly interface. The application shall be capable of simultaneous interaction in a multi-user environment.

The software shall facilitate RLDCs/NLDC to prepare day-ahead schedules as per IEGC 2010 (or any later version) including relevant amendments, currently in force. It will also facilitate the Constituent (Authenticated Users) members to submit / revise Declared Capacity(DC) and requisition and view / download schedules and related information as per respective members’ roles & privileges. Software will be based on layered architecture having separate layer for data, scheduling / revision logic and user interface. It will be grouped in modules and sub-modules and any exchange of data between them will be highly configurable. The bidder would be encouraged to provide application process interface (API) for addition, modification, replacing modules as per regulatory requirement to facilitate user updating. 2.5 Functional Requirement

This section describes the functional requirements expected from the scheduling application so as to perform energy scheduling as a vital activity of the RLDCs/NLDC. The application shall be modular and menu driven as already mentioned.

(16)

15

2.5.1 Configuration Module

This module shall have the provisions for System Administration and Configuration, namely, Creation/Deletion of User accounts, members and assigning roles & rights. Proposed Scheduling software shall incorporate three levels of role based user groups - viz., Application Administrator, Internal users (i.e., Administrator, Supervisor, Grid operator, General user within individual RLDC/NLDC) and External users(i.e., Generating Stations and Beneficiaries outside the concerned RLDC/NLDC). The number of members in each user group / sub-group shall be configurable. Different members will be using the various functionalities of the application software depending on the specific roles and rights. User management tree is given in Annexure-III.

The users shall be broadly managed under the following categories: i. Thermal generators (inclusive of Gas generators)

ii. Hydro generators

iii. Renewable generators (Wind generators and solar generators to be separate) iv. Beneficiary Utilities

v. RLDCs/NLDC

vi. Any other user as per requirement

Provision for editing details pertaining to generators/beneficiaries/constituents in data base by administrator at RLDCs/NLDC, namely:

i. Addition of new ISGS/LTA customer/MTOA customer with details like installed capacity, COD, etc.

ii. Addition of new Units of already registered generator along with details of IC, COD, etc.

iii. Provision of entering unit wise dead band, i.e, non-permissible range as declared by generators.

iv. Provision for entering ISGS specifications in ISGS data base. 2.5.2 User Log-in Module

This module will enable authentication and verification process to allow authorized members to log-in and access menus depending on his/her assigned roles & rights. Pre-configured rights shall determine and activate the modules and menu accordingly for the authenticated user. Attempt to log in by un-authenticated users will display appropriate message/remark in message window.

2.5.3 Share Allocation Module

Every beneficiary has shares allocated in an ISGS as decided by Ministry of Power from time to time. Shares are usually in percentage values however often MW quantum is also used for scheduling. Provision shall be there to incorporate both the options.

(17)

16

i. Share table shall be implemented using time dependent data storage technique so that retrospective schedule preparation/corrections are possible.

ii. Share allocations table shall be designed as ISGS vs Constituents table. iii. Provision for creating/editing/adding/deleting of existing and new

ISGS/beneficiaries shall require two level authentication.

iv. Provision for editing share allocations through two level authentications.

Modifications in share table shall be possible before the operating day and shall have provision to enter an effective date. The share allocation table shall be region specific with provision for incorporating allocations involving trans-regional beneficiaries, i.e., generators and beneficiaries are located in different regions.

2.5.4 Transmission Loss Module

Transmission losses are considered while scheduling. Transmission losses are presently computed by RLDCs every week for the region based on meter data. This regional transmission loss (LossReg) is further moderated in accordance to CERC (Sharing of Inter State

Transmission Charges and Losses) Regulations, 2010 amended from time to time. All data in this module shall be implemented using time dependent data storage tables. The Transmission module shall have the following provisions:

i. Entry of LossReg of all control areas of the regions on weekly basis by RLDCs.

ii. System should alert for entry of LossReg before commencement of the week.

iii. LossReg shall be editable on daily basis, if required, at RLDC.

iv. Transmission loss table based on all India POC result shall be implemented in this module.

v. Transmission loss shall be moderated as per slabs (Low, Normal or High) mentioned in point of connection (PoC) results before applying for scheduling. vi. Moderated transmission loss shall be maintained in database for every 15 minute

time block for the relevant date. It shall be possible to enter losses blockwise/ durationwise, if required in future.

vii. Provision for viewing moderated loss table for selected date shall be there.

Moderated regional transmission losses as per POC results are effective for specific period till subsequent results are notified by CERC. Presently, based on transmission losses POC results segregate the control areas into three slabs as per the following logic, viz.,

i. Low = (LossReg – 0.3)%,

ii. Normal = LossReg% and

iii. High = (LossReg + 0.3)%

The moderation factor, presently 0.3, shall be configurable by RLDCs/NLDC to implement future CERC notifications in this regard.

(18)

17

2.5.5 Regulation of Power Module

As per CERC order (Regulation of power) dated 28th September 2010, Power Supply Regulation imposed on a defaulting state by ISGS or Transmission Licensee should be as per procedure stated in Chapter III (REGULATION BY GENERATING COMPANY) and Chapter IV (REGULATION BY TRANSMISSION LICENSEE) of the Regulation. Regulation quantum shall be linked with concerned ISGS and displayed in separate column(s) showing whether regulated power is diverted to other state(s) or sale in Short Term Open Access.

i. For enabling implementation of power supply regulation, merit order list (as per energy charge) of ISGS is required and provision thereof to edit the same as and when required shall be provided within this module.

ii. Accordingly, regulated entitlement shall be stored in database and available for requisition by the concerned entity through the requisition module.

iii. Corresponding URS of particular generator (ISGS) arising due to regulation shall be maintained in database and made available to the other beneficiaries of the region through requisition module.

iv. The regulating ISGS should be able to view block wise regulated quantum in MW and total MU through their individual login a/c. There shall also be separate columns showing the dynamic URS based on requisitions placed by the beneficiaries or approved STOA transactions entered into in this connection.

v. Regulation report sheet to contain the details of regulation viz. effective period, constituent/constituents on which regulation has been effected, ISGSs from which affected, quantum of power reduced block wise, diversion of regulated power through requisitions, diversion of regulated power through STOA, etc.

vi. Roll back provision through appropriate schedule revision shall be there in case the regulation is revoked.

2.5.6 Availability Submission Module

As per IEGC 2010, by 0800 Hrs every day, each ISGS shall advise concerned RLDC, the ex-power plant Declared Capacity (DC) in MWh and MW (at 15 minute interval) foreseen for the next day, i.e., from 0000 Hrs to 2400 Hrs of the following day.

This functionality shall be invoked through an interface where user will be able to select the appropriate format from the menu for availability submission. The user interface formats for availability submission by Thermal ISGS, Hydro ISGS and Renewable generator shall be provided under different sub-modules (Thermal, Hydro and Renewable) within this module. User shall be able to submit the availability data as ‘day-ahead’ or ‘revised’ declaration for the concerned day, i.e, for ‘day of operation’ or for ‘day-ahead’ through a dropdown option. Database shall be updated through two (2) level confirmations, say, Submit followed by

(19)

18

i. Availability Declaration by Thermal stations shall include the following: a. Declaration for each of the 15 minutes time blocks

b. DC should be allowed to enter in round figure only c. Ramp Up

d. Ramp Down

e. Technical Maximum / Minimum of generation f. No. of Units on Bar

g. Average declared capacity of 96 block(in ex-bus MW) for both normal as well as fuel shortage condition (as per CERC terms and conditions of tariff regulation) h. Generator user base (say ISGS, IPP, Merchant, Shared project, etc)

i. Variable charge(Rs/Kwh) j. Comment/Remark.

ii. Availability Declaration by Hydro stations shall include the following:

a. Declared Energy for nth day (En) where nth day means ‘tomorrow’ for which day

ahead scheduling is being prepared.

b. Declared Capacity (Max. generation for at least three hours of nth day )

c. Declared availability (MWh) En-3 & actual generation (MWh) An-3 data for 3 days

prior to nth date. Declared availability En-3 can be accessed from the database

but An-3 shall be furnished by the generator. This is required to arrive at

schedule for nth_{day, S}

n = En + (An-3- En-3) as per clause 6.5.13 of IEGC to

incorporate flexible hydro scheduling.

d. Dead band (vibration zone) in MW of generating units e. Declaration for each of the 15 minutes time blocks f. DC should be allowed to enter in round figure only

g. Generator user base (say ISGS, IPP, Merchant, Shared project, etc) h. Variable charge(Rs/Kwh)

i. Comment/Remark

iii. Declaration by Renewable Generators (Wind and Solar generators sub-modules shall be separate and procedure for scheduling renewable shall be implemented as stated in IEGC) shall include the following:

a. Declaration for each of the 15 minutes time blocks b. DC should be allowed to enter in round figure only c. Ramp Up

d. Ramp Down

e. Technical Maximum / Minimum of generation.

f. No. of Units on Bar

g. Comment/Remark

Each ISGS shall enter their Declared Capacity through their individual login account. On completion of declaration by all the ISGS, a pop up message to be enabled seeking for further action by RLDC. In case of any technical problem in doing the same by ISGS, RLDC shift

(20)

19

engineers to co-ordinate in entering the DC through respective group login ID. Provisions to enter one time user details like ramp up/ ramp down rates, technical minimum applicability, unit wise / group wise / plant wise / special category plant which would be editable if required. Provision shall also be made to facilitate revision of previously declared availability along with reasons thereof, as per the relevant clauses of IEGC. However to submit requests for revisions by generators all the fields as in the original availability declaration should also be complete without which the request shall not be accepted by the system.

All data exchanged through this interface are to be maintained in data base for relevant date. Each interaction shall be logged with unique reference ID accessible to users and RLDCs/NLDC concerned. Message regarding submission of capacity declaration/revisions should be system generated from the generator side after confirmation. This should appear in a message area to the generators/beneficiaries/RLDC and should be archived as sequence of events (SOE) for the relevant date.

2.5.7 Entitlement Module

i. Entitlement for each state shall be prepared based on Share allocation table and declarations by each ISGS.

ii. Considering Monday to Sunday week period, ‘Weekly Loss updated’ [Yes/No] pop up menu and an alert message window “Please enter weekly loss” should appear while preparing entitlement / schedule of each Monday only if same is not updated in database. This will serve as a reminder/confirmation that appropriate loss has been entered.

iii. Entitlement shall be displayed for each state through consolidated page with information of each ISGS availability and entitlement. In addition, for hydro stations, additional columns showing availability considering flexible hydro scheduling and corresponding entitlement shall be displayed.

iv. Entitlement of each state shall be viewed through individual state login only. However, every RLDC can access the entitlements of every beneficiary in their respective control area.

v. Suitable message should appear in the message area declaring entitlements have been prepared. This should also be archived in the SOE for the day.

vi. Facility shall be available to include Entitlements of embedded entities also.

vii. Columns shall be made available for including availability of LTA/MTOA transactions.

(21)

20

2.5.8 Requisition Module

i. Every beneficiary should be able to access the requisition module through their authenticated login.

ii. The module shall permit data submission by beneficiaries under various columns, viz.,:

a. Requisition (upto Entitlement)

b. Surrendered quantum (URS derived as Entitlement – Requisition) c. Reallocation (requisition against URS by other beneficiaries) and

d. Regulated reallocation (requisition against URS due to power regulation) Option for URS requisition shall be made available to the beneficiaries of that particular plant only. Any submission against surrendered quantum shall be dynamically added to the URS and details shall be available to concerned beneficiaries for requisition.

iii. The entitlement/quantum available for requisition against every 15 minute time block for each options mentioned above shall be facilitated.

iv. Beneficiaries shall give requisition for every 15 minute time block against each ISGS or LTA/MTOA transactions. Option shall be there to enter requisition for every time block or a sequence of blocks. Full requisition/NIL requisition for round the clock should be possible through a single click.

v. Requisition more than the corresponding entitlement shall flash ‘Invalid entry’ message against the relevant time block(s).

vi. First instance of submission of requisition shall be considered as day-ahead requisition. Subsequent submissions through this channel shall be treated as revised requisition with provision for assigning reason for revision. Accordingly system generated revision request code shall be assigned.

vii. Requisition of URS (partial or full) power by a constituent other than the original beneficiary shall be scheduled. Further, if URS is subsequently reclaimed back by the original beneficiary then it should be possible to roll back the URS from requisitioned constituent and reschedule it back to the original beneficiary.

If more than one beneficiary has declared URS and more than one utility submits requests for URS requisition, allotments shall be made on pro-rata basis against individually declared URS. URS already allotted shall not be reduced for a fresh requisition by another entity. In case of availability revision wherein revised declaration is less than the earlier declaration, URS also shall be to be revised accordingly.

viii. All system interaction should be logged and archived in SOE for the day. Moreover, message indicating receipt of revision requests and its status whether revision

(22)

21

executed or pending should be displayed in the message area to all authenticated users. To avoid cluttering of display interface, messages beyond say 8-10 most recent ones shall not appear in the message area. However these shall be available as SOE on a new window when selected by the user from the menu.

2.5.9 MTOA Module

Medium term open access (MTOA) transactions are required to be incorporated in the schedule to finalize the drawal / injection schedules of regional entities. RLDC(s) shall incorporate the quantum of power to be exchanged in day-ahead schedules, which includes the MTOA transactions approved by CTU.

i. Provision for entering MTOA transaction details like approval no., quantum, buyer, seller, traders, route, region involved, etc in database upto 12 (twelve) months in advance for scheduling.

ii. Provision to incorporate subsequent revisions (including real time revisions) of MTOA transactions (real time revisions - RLDC operator intervention).

iii. Whereever other RLDC(s) are involved such details must be exchanged through system provided data transfer facility initially in CSV format. However, XML formats for data exchange should be supported.

iv. Provisions for manual data entry should be there whenever circumstances require such intervention.

v. Due to operational considerations transactions are often required to be wheeled through intervening region(s). The software should have provision to effect such wheeling of power.

vi. Access to MTOA transactions to be provided to corresponding applicant involved based on approval no.

Loss Computation for LTA and MTOA

Treatment of LTA/MTOA transactions while scheduling is same as far as Transmission Loss is concerned and is illustrated below.

Let us consider a case where the Injecting DIC is located in Region-1, Drawee DIC is located in Region-3 and let the contracted quantum power be P. Let us also consider a intervening region Region-2 for illustration. Further let Effective PoC Loss percentage of the injecting DIC in Region-1 be ‘a’ and that of drawee DIC in Region-3 be ‘b’.

(23)

22

The injecting DIC has to inject: P

The schedule at inter-regional boundary between Region-1 and Region-2 shall be P and that between Region-2 and Region-3 shall also be P.

The schedule of drawee DIC shall be S = P*(1-a/100)*(1-b/100)

If the injecting utility is an embedded entity then the loss of utility where the injecting entity is embedded, shall also be considered in computing drawee schedule for MTOA transactions. 2.5.10 STOA Module

Short term open access (STOA) transactions are bilateral power transactions which need to be incorporated in the schedule to finalize the drawal / injection schedules of regional entities. RLDC(s) shall incorporate the quantum of power to be exchanged in day-ahead schedules, which includes the STOA transactions approved under various categories.

i. Provision for entering STOA transaction details like approval no., quantum, buyer, seller, traders, route, region involved, etc in database upto 4 (four) months in advance for scheduling.

ii. Provision to incorporate STOA transactions through import / access to .csv file / database of STOA program.

iii. Provision to incorporate revisions (including real time revision) in STOA transactions through import / access to .csv file / database of STOA program (real time revisions - RLDC operator intervention).

iv. Whereever other RLDC(s) are involved such details must be exchanged through system provided data transfer facility initially in CSV format. However, XML formats for data exchange should be supported.

As alternate arrangement for such transactions where other RLDC(s) are involved, a provision for manually entering the transaction details by the counterpart RLDC(s) needs to be incorporated.

v. Scheduling of URS (either on account surrender by beneficiary or imposition of Power Regulation) as STOA transaction shall be facilitated within this module.

REGION1 Loss a% Injecting DIC (P MW) REGION2 (P MW) REGION3 (P MW) Loss b% Drawee DIC (S MW)

(24)

23

vi. Provisions for manual data entry should be there whenever circumstances require such intervention.

vii. Due to operational considerations transactions are often required to be wheeled through intervening region(s). The software should have provision to effect such wheeling of power.

viii. Access to STOA transactions to be provided to corresponding applicant involved based on approval no.

Loss Computation for STOA (bilateral transaction)

Application of Transmission Loss for the purpose of scheduling STOA transactions under PoC methodology is illustrated below.

The same is pictorially represented as below.

The injecting DIC has to inject I = P/(1-a/100)

The schedule of drawee DIC shall be S = P*(1-b/100)

2.5.11 Wheeling of LTA/MTOA

Due to operational considerations transactions are often required to be wheeled through intervening region(s). The software should have provision to effect such wheeling of power for LTA/MTOA and STOA transactions.

REGION1 Loss a% Injecting DIC (I MW) REGION2 (P MW) REGION3 (P MW) Loss b% Drawee DIC (S MW)

(25)

24

2.5.12 ATC Module

Each RLDC will communicate to NLDC, by 0900 Hrs every day the ATC Margins for Export and Import (96 time block format) for the identified corridors and flow gates to facilitate Collective Transactions by Power Exchanges (PX) as per STOA Regulations. Available Transmission Capability (ATC) is computed as per the expression below,

ATC = TTC – RM where TTC= Total Transmission Capability and RM= Reliability Margin TTC and RM are user inputs and should be implemented in the database as time dependent data. For the purpose of facilitating Collective Transactions by Power Exchanges (PX) ATC Margin is computed for both export and import scenario separately as per the expression, ATC Margin = TTC – RM – LTA – MTOA – STOA

All data in respect of TTC, ATC, RM, LTA, MTOA & STOA shall be in MW.

i. ATC Margins shall be computed for every 96 time blocks for export and import separately (wherever applicable). Computation of ATC margins in a particular direction shall take into consideration counter LTA/MTOA.

ii. By default, ATC for the present day to be carried forward as ATC for the next day until changed.

iii. Provision to revise ATC along with reason and revision no. (ATC revision instance shall be different from the schedule revision instance) as and when required needs to be incorporated. ATC shall be computed every time a user (RLDC) desires to calculate the same based on changed scenario or otherwise.

iv. The same shall be made available to NLDC for facilitating collective transactions by PXs. The data transfer would be initially in CSV format. However, XML formats for data exchange should be supported.

v. System generated message should appear in log and should be archived in the SOE for the day. All ATC calculated for the day shall be logged and shall be retrievable along with relevant details by system administrator.

2.5.13 Power Exchange Module

Power exchanges provide a transparent platform for transaction of power within and across the regions. Regulation envisages multi exchange operation in India. Presently two power exchanges are operating in the country with a third exchange already approved but not operational. The details of these transactions called collective transactions are received at concerned RLDCs from respective PXs through NLDC.

i. Data from Power Exchange files (IEX, PXI or any other power exchange) sent by NLDC shall be imported & saved separately in database for each exchange.

(26)

25

ii. Relevant details like Injecting utility, drawee utility, regional or inter-regional transaction, regions involved, path of the transaction etc shall be extracted from the PX files for future reference.

iii. Transactions shall be accordingly scheduled for the concerned regional entity after application of transmission loss.

Loss Computation for STOA (collective transactions)

Application of Transmission Loss for the purpose of scheduling collective transactions under PoC methodology is similar to STOA transactions and is illustrated below.

Then the injecting DIC has to inject I = P/(1-a/100)

The schedule of drawee DIC shall be S = P*(1-b/100)

This is exactly same as discussed under similar example in section 2.5.10 2.5.14 Create/View Schedule

The ‘create schedule’ option shall be permitted for the RLDC personnel only while viewing shall be permitted to all authenticated users.

i. State-wise LTA, MTOA & STOA (bilateral) shall be displayed separately which RLDC operator can access & modify if required through the appropriate modules.

ii. Considering summation of all requisitions submitted by the Constituents against each ISGS as well as LTA, MTOA , STOA and URS; the same shall be checked against ramping rates, technical minimum value, dead band (in case of hydro generators), etc and moderated accordingly if required. The injection schedule thus arrived at should be displayed showing availability, adjusted schedule, URS, etc for each ISGS for the day for every 15 minute time block.

iii. If total generation of an ISGS in a particular block/blocks falls within a Dead band (vibration zone) as declared by ISGS, which should be highlighted by the software for rectification by the RLDC operator.

iv. In case of MTOA & STOA (both bilateral & collective), injection loss & withdrawal loss (PoC loss) shall be considered for both intra & inter regional transaction, as the case may be. This shall be facilitated from the data under Transmission Loss module.

(27)

26

v. In case of LTA transactions, withdrawal loss (PoC loss) as applicable shall be implemented.

vi. Generation and drawal schedules shall be created based on the summation of all transactions, viz., LTA, MTOA & STOA (both bilateral and collective). Inter-regional schedules shall also be available for viewing based on relevant data.

For each constituent complete view of respective schedule should be available showing all details like, allocation from each ISGS, URS, LTA, MTOA, STOA (bilateral, collective and URS) transactions, etc.

2.5.15 Schedule Revisions

The schedules undergo revisions on account of various reasons and have to be facilitated accordingly. The revisions requirements and adopted procedure as per IEGC are mentioned herein.

i. Revision by ISGS

a. Revision request shall be submitted along with fresh availability. Submission of revision request under unit tripping case only, shall be permitted when the request concerns revision for time blocks wef 4(four) time block or later, counting the prevailing time block as 1st block. This can be facilitated through selection tool to mark the request as unit trip revision request. For all other revisions, request submission shall be permitted only if revisions have been requested for time blocks wef 6(six) time blocks counting the prevailing time block as 1st block.

b. In case of run of river (RoR) hydro ISGSs, schedule revision request shall be allowed on 6(six) hourly basis for the same day viz., 0600 Hrs, 1200 Hrs, 1800 Hrs and 2400 Hrs. While allowing submission of such revision request limitations regarding 4(four) and 6(six) time blocks as described earlier shall be applicable.

c. In case of pondage based hydro generator, submission of schedule revision requests shall be permitted only if the variation in availability (MWh) is more than 2% (percentage shall be configurable) compared to the earlier declaration.

d. There shall be maximum of 8 revisions for each 3 hour time slot starting from 00:00 hours during the day for wind generators.

e. To discourage frivolous revisions, an RLDC may, at its sole discretion, refuse to accept schedule/capability changes of less than two (2) percent of previous schedule/capability. Such variation threshold, presently 2%, shall be configurable by the RLDC. If the request involves variation less than the threshold for any time block the same should be marked distinctively and

(28)

27

‘invalid entry’ message should pop up. Request submission shall not be permitted in such cases.

ii. Revision by beneficiaries

a. Less requisition/surrendered of scheduled energy wrt entitlement by beneficiaries shall be allowed if the request concerns revision wef 6th time block counting prevailing time block as 1st block.

iii. Revision by RLDCs

a. In case of schedules involving trans-regional constituents, revision by generator(s) and/or beneficiaries shall be permitted as detailed earlier in clause i and ii above. However, in such cases the issue of matching inter-regional tie line schedules is vital for subsequent commercial consideration of scheduled transactions. To facilitate this there should be provisions to incorporate such revisions involving trans-regional constituents across all the concerned regions without any manual intervention.

b. OA curtailment and revision

OA curtailment may be full or partial. Curtailment may happen due to various reasons like congestion in certain area which in turn affects other areas/electrical regions, HVDC pole tripping, inability to supply/generate as per contracted capacity, massive load crash, inclement weather conditions, etc. When curtailments involving large number of transactions are to be effected on short notice and on selective basis as per OA rules & guidelines, the problem becomes all the more tricky and cumbersome.

i. Curtailment sequence shall be STOAs (Bilateral followed by Collective transactions) followed by MTOA and finally LTA.

ii. Software should be able to group STOA under import and export for every time block to implement the above curtailment sequence as and when called upon. iii. Provision to input the direction of curtailed route (Import or Export) and MW

margin available/quantum of MW to be curtailed on the Inter regional periphery should be incorporated in the user interface where OA’s are to be scheduled block wise.

iv. Based on above information it should be possible to compute the percentage curtailment based on MW margin available or quantum of MW to be curtailed on the Inter- regional periphery (Import or Export) block wise vis-à-vis the corresponding scheduled STOA . The same shall be accordingly affected on all the transactions (Import or Export) on the assigned route on pro rata basis as per the above preference.

(29)

28

Vice versa, it should also be able to effect the curtailment if the percentage curtailment figure and curtailed power flow directions are assigned. Therefore, provision for manually entering the percentage curtailment figure also needs to be incorporated.

v. After all OA curtailment revision is implemented, a validation/web upload preview sheet needs to be generated where the quantum of curtailed power matches with the quantum of power specified to be curtailed before uploading in the official web page.

vi. In case of another RLDC’s server problem leading to either returning garbage data (data type inconsistencies) or not able to access the remote server, undoing provision for retaining the old schedule need to be incorporated. Alternatively, manual entry of the relevant transaction(s) shall be facilitated. Generally revisions shall be effected through submission of revision requests from the constituents or suo-moto by RLDCs. To facilitate revisions the following common provisions shall be incorporated in the application software.

i. Every constituent shall request for revisions through their respective login a/c. In case of any problem same may be communicated to submit the request on their behalf.

ii. Provision for entering the reason for revision by constituents shall be incorporated. iii. Revision request shall require two level confirmations before submission.

iv. Once revision request is submitted no editing shall be possible and further request shall be in the form of additional revision request.

v. All revision request submitted shall be logged with unique ID and shall appear in the job queue window. Details of particular revision request shall be available on selection by users.

vi. Job queue shall be refreshed as and when service requests are received. Service requests once attended shall not appear in the job queue. However an audit trail shall be maintained separately.

vii. ‘Invalid entry’ message should pop up when a hydro station tries to submit a revision request after inadvertently entering availability or actual generation (after grid exigency) which is more than DC in one or more time blocks.

viii. Provision shall be there in case any revision is to be made out of turn as per system requirement by RLDC. This provision is to be made available for RLDC only.

ix. If revision requested by ISGS is rejected/partially revised by RLDC then remark option for mentioning the reason for rejection to be provided along with the revised schedule.

(30)

29

x. The stipulated limitations regarding time blocks for revision of schedules (presently 4th and 6th time block) shall be configurable to take care of any change in IEGC in this respect.

xi. In case any violation is detected in the data based on various configurations, the submit button should be disabled with a pop up message mentioning the probable clause of IEGC or Regulation violation. The pop up message shall be configurable at RLDC end only.

2.6 User Interface Requirement

This chapter describes the user interface requirements for the application software. Software shall be modular i.e. functionally partitioned into discrete, scalable, reusable (whereever possible) modules consisting of isolated self contained functional elements and designed for ease of change or modification. The system shall make maximum use of common industry standards for interfaces. The application shall be menu driven. All functions of proposed application shall be accessible through web browser and user interfaces. All user interactions shall be through these user interfaces. The user interface requirements specified in this section are applicable for the user interface application of the web based scheduling application and all features and functions shall be available to the user, except for certain functions for which access is deliberately restricted according to access control restrictions. All violations and events shall be reported to the user along with date and time (Indian Standard Time) tags.

The application shall provide appropriate user interfaces for the data submission and viewing. The user interfaces shall be selected based on the functionality called for from the menu. Considering the requirements for energy scheduling the following user interfaces are envisaged.

i. Interface for system configuration*

System administrator shall use this interface to configure the users and assign rights and permissions accordingly. The creation of users and assigning appropriate rights and permissions shall be offline and shall require submission of details regarding the user. The user profiles shall be ultimately stored by RLDCs/NLDC in the database for better user management.

ii. Interface for user login.

This interface shall facilitate access to the authenticated users as per existing industry standards based on user configuration by the system administrator. iii. Interface for availability declaration.

This data is required from a broad user group consisting of mainly Thermal generators, Hydro generators and most recently Renewable generators (viz., Wind generators and Solar generators). Accordingly, generators shall submit appropriate

(31)

30

data like availability, technical minimum, ramp rates, actual generation etc based on the fuel used to facilitate scheduling as per IEGC. It is therefore desired to have separate user interfaces for these broad categories of generators. The interface shall employ sufficient flexibility regarding time blocks (individual, group of blocks, etc). However inputs collected over this interface shall be interpreted and stored in database on a 96 time block format.

In addition data regarding revision requests shall also be facilitated through the same interface with appropriate provisions to distinguish between day-ahead declarations and subsequent revised declarations under revision requests.

iv. Interface for transmission loss*

This interface shall be used by RLDCs/NLDC to facilitate PoC loss configuration, scheduling loss, input weekly regional transmission loss based on meter data, etc. editing and modification of the data and associated formula shall be possible through this interface.

v. Interface for share allocation*

This interface shall be used by RLDCs/NLDC to facilitate allocation of power from different generators to the beneficiaries. Allocations shall be mapped accordingly for computing entitlement.

vi. Interface for Regulation of Power*

This interface shall be used by RLDCs/NLDC to implement power regulations on the defaulting constituents as per CERC order on Regulation of Power.

vii. Interface for Entitlement*

This interface shall be used only by RLDCs/NLDC to prepare entitlements of beneficiaries. Entitlements shall be computed based on the availability declared by ISGSs and share allocations. Entitlement once computed shall be available to all including trans-regional beneficiaries under their requisition interface.

viii. Interface for submitting requisition

This interface shall be used by beneficiaries to submit respective requisition as explained under Requisition Module in Section 2.5.8. Requisitions concerning trans-regional beneficiaries shall be seamlessly communicated to all RLDCs depending on where the beneficiaries and ISGS are located.

In addition submission of revised requisition shall also be facilitated through the same interface with appropriate provisions to distinguish between day-ahead requisition and subsequent revised requisition under revision requests.

Web Based Energy Scheduling

POWER SYSTEM OPERATION CORPORATION LIMITED

Western Regional Load Dispatch Centre

F-3, MIDC Area, Marol, Andheri (E)-Mumbai-400093

Technical Specification (TS)

For

Web Based Energy Scheduling

In

Regional Load Dispatch Centres

and

Table of Contents