Web Based Energy Scheduling

Transcription

1 POWER SYSTEM OPERATION CORPORATION LIMITED Western Regional Load Dispatch Centre F-3, MIDC Area, Marol, Andheri (E)-Mumbai Technical Specification (TS) For Web Based Energy Scheduling In Regional Load Dispatch Centres and National Load Dispatch Centre

2 Table of Contents Section Introduction Existing Scheduling Practice Purpose of this Document System Architecture Hardware Section Software Section General Requirement Scope of Work Bidder s Scope of Work Exclusion from Bidder s scope Facilities to be provided by RLDCs/NLDC for Project Implementation Implementation Outline of Scheduling Software Project Implementation Plan Section General Energy Scheduling Scheduling Philosophy Project/Product scope Functional Requirement System Configuration Module User Log-In Module Share Allocation Table Transmission Loss Module Regulation of Power Module Availability Submission Module Entitlement Module Requisition Module MTOA Module

3 STOA Module Wheeling of LTA/MTOA and STOA ATC Module Power Exchange Module Create/View schedule Schedule Revision User Interface Requirement Database Requirement Data Exchange Requirement Data Exchange with Systems Internal to POSOCO Data Exchange with Systems External to POSOCO SCADA Interface Security Requirement Reporting Requirement Event Log Generation Performance Requirement Bill of Quantity(BOQ) Section General Factory Acceptance Test Site Acceptance Test Availability Test Section Training Documentation Section General Resolution Time Schedule Scope of Work

4 5.4 Modification during Warranty/Maintenance Period Availability Computation Section RLDCs/NLDC specific customization Annexure Annexure-I Annexure-II Annexure-III Annexure-IV Annexure-V ************* 3

5 1.1 Introduction SECTION 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 interregional 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, multidimensional 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 4

6 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. 5

7 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 Hardware Section Hardware supply and the activities mentioned herein shall be in user scope, i.e., respective RLDCs/NLDC as specified in Section 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 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 6

8 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 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 7

9 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 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. iii. Software Requirements Specifications for web-enabled energy scheduling software solution. Connection and interfacing of users with application software. 8

10 iv. Coordination with different machines / servers / database and proper handshaking amongst the systems installed. v. Database development, Displays and Reports. vi. vii. viii. ix. Normalized structure of database. Secured high availability of application software. Training of POSOCO personnel 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), (iv), (iv), 2.8.1, and of this document but not essential for project implementation. xi. Support and Maintenance during (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 Exclusion from Bidder s Scope i. All Hardware as mentioned in Section ii. Environment (OS, DBMS, etc) as mentioned in iii. All necessary permission / clearances for installation, testing, commissioning of the Energy Scheduling software 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 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. iii. iv. Providing power supply outlets for site development/configuration of bidder equipment, if any. Providing storage space at sites wherever available. All permission at site for carrying out installation, testing & commissioning, training, etc. 9

11 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. 10

12 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 End of Section

13 SECTION General Web Based Energy Scheduling Software-Functional Requirements 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. 12

14 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:- Block Block Block Chronology of day ahead scheduling activity in time line format is shown below to represent the interaction of various users. ISGSs submit availability ATC to NLDC Entitlement to Beneficiaries ATC to PX by NLDC Collective transaction request to NLDC by PXs NLDC informs congestion to PXs PXs gives congestion relieved transaction request to NLDC 1500 SLDCs submit requisition to RLDCs 1600 NLDC forwards collective transactions to RLDC RLDC confirms acceptance to NLDC NLDC forwards acceptance to PXs RLDC issues R0 schedule PXs informs collective transactions to SLDCs rega SLDCs/ISGSs inform modifications to RLDCs RLDCs issue R1 schedule

15 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. 14

16 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 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 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. 15

17 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 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 (Loss Reg ) 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 Loss Reg of all control areas of the regions on weekly basis by RLDCs. ii. System should alert for entry of Loss Reg before commencement of the week. iii. Loss Reg 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 = (Loss Reg 0.3)%, ii. Normal = Loss Reg % and iii. High = (Loss Reg + 0.3)% The moderation factor, presently 0.3, shall be configurable by RLDCs/NLDC to implement future CERC notifications in this regard. 16

18 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 Availability Submission Module As per IEGC 2010, by 0800 Hrs every day, each ISGS shall advise concerned RLDC, the expower 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 Confirm. 17

19 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 n th day (E n ) where n th day means tomorrow for which day ahead scheduling is being prepared. b. Declared Capacity (Max. generation for at least three hours of n th day ) c. Declared availability (MWh) E n-3 & actual generation (MWh) A n-3 data for 3 days prior to n th date. Declared availability E n-3 can be accessed from the database but A n-3 shall be furnished by the generator. This is required to arrive at schedule for n th day, S n = E n + (A n-3 - E n-3 ) as per clause 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 18

20 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 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. viii. Entitlements shall be rounded off to the nearest two decimal for each transaction. 19

21 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 20

22 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 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. The same is pictorially represented herein. 21

23 REGION1 Loss a% Injecting DIC (P MW) REGION2 (P MW) REGION3 (P MW) Loss b% Drawee DIC (S MW) 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 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. 22

24 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. 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. The same is pictorially represented as below. REGION1 Loss a% Injecting DIC (I MW) REGION2 (P MW) REGION3 (P MW) Loss b% Drawee DIC (S MW) The injecting DIC has to inject I = P/(1-a/100) 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-b/100) 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. 23

25 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 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. 24

26 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. 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. Then the injecting DIC has to inject I = P/(1-a/100) 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-b/100) This is exactly same as discussed under similar example in section 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. 25

27 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 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 1 st 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 1 st 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 26

28 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 6 th 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. 27

29 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. iii. iv. Provision for entering the reason for revision by constituents shall be incorporated. Revision request shall require two level confirmations before submission. 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. vii. viii. ix. 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. 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. 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. 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. 28

30 x. The stipulated limitations regarding time blocks for revision of schedules (presently 4 th and 6 th 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 29

31 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 Requisitions concerning transregional 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. 30

32 ix. Interface for LTA, MTOA and STOA This interface shall facilitate submission of (a) relevant data pertaining to LTA and MTOA transactions and (b) requisitions pertaining to STOA transactions. These shall be in addition to the approved transactions already available in the database. Moreover, both bilateral and collective transactions shall be addressed within this interface to facilitate a single interface for STOA transactions. 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. Curtailment of the transactions shall also be possible by RLDCs only based on pre configured methodology. x. Interface for ATC* This interface shall be solely used by RLDCs to calculate current ATC under export and import scenario. The same should also be communicated seamlessly to NLDC through appropriate action within this interface. xi. Interface for schedule* This interface shall be used solely by the RLDCs to prepare the drawal and dispatch schedules for the respective beneficiaries and the ISGSs who are within the control area of the particular RLDC. In cases where trans-regional beneficiaries are involved, only the relevant portion of the dispatch schedule of the concerned ISGS(s) shall be seamlessly communicated to the RLDC(s) involved. xii. Interface for viewing schedule This interface shall be used by all the constituents and NLDC to view their respective schedules. No data editing shall be permitted in through this interface. However, facility to download the schedule in multiple user defined formats, like, excel, pdf, etc shall be provided within this interface Though the RLDCs/NLDC shall have complete access to all modules of the application including interfaces, the interface marked (*) shall be accessible to RLDCs only and only those interfaces which require user inputs(availability, requisition, etc) from the constituents shall be given appropriate access as per system configuration. 2.7 Database Requirement Database shall be Oracle 11i or later version. The database will be installed on two identical servers as main and standby. The REAL APPLICATION CLUSTER (RAC) will be implemented on both the server to work as main and standby server. The data storage will be done on the 31

33 external storage while the oracle software will be installed on local HDD of each oracle server. Both the oracle server will share the external storage for data writing and reading. External storage will have RAID implemented for data security. The power supply to both the server as well as external storage will be dual i.e. main and standby. The installation of OS, ORACLE and RAC will be the done by the respective vendors and is under employer scope. However, bidder shall coordinate with OS/database (ORACLE) vendor for any project related configuration details/requirements and involve user RLDCs/NLDC under all such circumstances. 2.8 Data Exchange Requirement Scheduling software system envisaged to be developed here is required to exchange data with other systems. Data exchange may be divided in two categories, viz., data exchange with system internal to POSOCO and data exchange with other utilities which are external to POSOCO. A tentative list of systems for both the categories is given in the tables Table 1 and Table 2. The detailing and finalization of the same shall be done during SRS finalization stage. Scheduling software shall fulfil all requirements of data exchange Data exchange with systems internal to POSOCO Exchange of data from any of the internal system of POSOCO shall be seamless, without requirement of manual intervention and shall be in loosely coupled manner. Scheduling software shall expose pre-defined web services which may be used by other software system for importing as well as exporting of data. Since, other systems of POSOCO are yet to be made capable for consuming the web services, the data exchange format shall be agreed upon during SRS development phase. Format used may be JSON or XML for which schema shall be decided during development of SRS. However, bidder may suggest any other better format which may improve the performance along with meeting the requirements of this technical specification. Decision of POSOCO shall be final. POSOCO envisages data exchange in XML format with SCADA system as well as with market operation system. Hence, scheduling software should also be made capable to export and import data in XML format. Bidder should create required flexibility in the software for the same. Since, at present data exchange with other internal systems being done through Comma Separated Values (CSV) files, proposed scheduling software shall also export in Comma Separated Values (CSV) files and import data from CSV files. Column definitions for the same shall be provided by POSOCO during SRS development phase. Table 1: Data exchange with systems internal to POSOCO Sl.No System Exported Data Imported Data Periodicity 1 Short Term Open Access System Bilateral Transactions LTOA Transactions/ MTOA Transactions/ Curtailed Transactions Twice Daily 32

34 Sl.No System Exported Data Imported Data Periodicity Metering & Settlement System RLDC fee and charges System Other RLDC Scheduling System Px Transaction Management System SCADA/EMS System - Implemented Scheduled Transactions Daily - Allocations Weekly Inter-regional Exchange Collective Transactions - Inter-regional Exchange Daily - Daily Scheduling Transactions On every change Data exchange with systems external to POSOCO Scheduling system is required to provide data to the constituents (Other power utilities, generating stations etc). At present this data is provided in CSV files. Constituents have developed their system which can import data from these CSV files. However, this process requires manual intervention and tight coupling of both systems. Moreover, constituents are in the process of automating their process. Constituents are also required to provide/upload data to the scheduling system of POSOCO. At present, constituents are providing this data by entering the values in web based forms or sending the same through fax/ which is entered by the concerned RLDC in existing scheduling system. In this context, user interface requirements (Section 2.6) for manual entries have already been described. In addition, scheduling system shall also have the facility to upload or send data automatically from constituent systems to the RLDC scheduling system. All data exchange with constituent systems shall be carried out through CSV file transfer as well as through RESTful and SOAP web services. Web services shall transfer data in JSON and XML formats. JSON and XML schema will be finalized /provided by POSOCO. All web service communication shall take place on SSL communication with authorized subscriber only. Normally all exchange shall take place in pull or query based method form constituent side except some of the message/data like last revision number etc. All uploading and downloading of data shall be affected by calling respective web services exposed by scheduling system. Before responding to any call to a web service, scheduling system should first authenticate the caller then check the authorization for access. In case of unauthorized call it should provide the feedback to the caller. After authentication and authorization success, scheduling system should validate the data format against the schema, before importing sent data or exporting required data. 33

35 List of data exchanges that may be required with the constituents is given below:- Table 2: Data exchange with systems external to POSOCO Sl.No. Data Set To the From the Periodicity constituents constituents 1 Declared Capacity - Yes Daily 2 Revisions - Yes On every change 3 Entitlements Yes - Daily 4 Revisions Yes - On every change 5 Requisitions - Yes Daily 6 Revisions - Yes On every change 7 Schedule Yes - On every change 8 Revision Yes - On every change SCADA Interface Energy Schedule data would be integrated with EMS/SCADA system for update and further application purposes at SCADA end. In order to transfer data on every changes / every block, initially CSV/XML format is to be implemented based on standard procedure. The data transfer would be for the current (nth) block data and immediately preceding (nth -1) and successive (nth +1) block data. Separate view would be provided at Energy Scheduling system to select data point to be transferred to EMS/SCADA. Bidders are encouraged to implement changed based data points transfer for given scenario otherwise complete selected data points would be transferred. Typical XML schema for SCADA interface would be provided by POSOCO. 2.9 Security Requirement The application shall employ industry standard user management system to meet physical security requirements like measures to prevent unauthorized access to the features and functions of the system. Only authenticated users shall be allowed access to the system. Separate logins with different roles to be provided for users based on the requirement of operation. Administrator will have the overall control over all the. Necessary logs for all interaction done by any user shall be maintained and shall be available to the System Administrator. Software should use HTTPS protocol for communication with client browser and shall be capable to upgrade for certificate based security. The system shall provide an integrated security system that allows administrators to create user and grant permission to different users (entities, States, Generating Stations, OA customers, etc.) with multiple interface points behaving as one. The user definition shall be hierarchical and logically inter-related in database also. The definition of such entities shall include various data attributes, i.e., station name, address, installed capacity, type of 34

36 generator, agreed capacity, standard auxiliary consumption, heat rate, etc. whichever is required. All users shall have access to relevant features and functions of the application based on their roles and requirements. Users shall be able to interact with the system, submit data, view schedules, log service requests, etc. The system shall allow administrators to create groups of users with same permission set. All users assigned to a given group shall have same permissions at system level. Each user belonging to a group (beneficiary/isgs) shall be able to open at most 2 simultaneous sessions (configurable by administrator) through authenticated login. There should be session time out if no activity is performed for 30 minutes (configurable by administrator) Reporting Requirement Scheduled data is required for user defined pre-formatted reports and same shall be facilitated through appropriate interface/templates. The application shall provide reporting tool using reporting tools like Crystal Reports or any other tools with better features for generation of Textual (Data) reports and Graphical (Pie- Chart, Bar-Chart, Line Graph, 3-D, worm plots, etc) reports. Internal users within RLDCs and NLDC shall also be able to prepare custom reports using the tool. Application shall have provisions for porting relevant data through xls, csv, pdf, dbf(foxpro) and xml formats. Bidder and RLDCs/NLDC shall define the formats of predefined reports and data to be ported during post award discussion as envisaged through customization under bidder scope. Typical report samples shall be submitted during post award discussion. Bidder shall prepare these predefined reports formats and these predefined reports shall be a deliverable item. i. All the report sheets should have block nos. as well as block in time. All reports to have the name of RLDC/NLDC and POSOCO emblem. ii. Every report to have a space for remarks. iii. All reports to be in printable/downloadable form. iv. All the reports to be within the paper margin. In case of reports with tabulated data which may exceed the paper margin, the section of report consisting of the data exceeding the paper margin should be generated along with all the other features (column and row labels, header, footer, etc) that were present in the earlier section of the report. v. A blank template shall be provided so that required queries/reports can be generated from the database. vi. All report sheets to have an uploading/print preview feature before final uploading to public domain. Data from all the report sheets to be exportable in excel/ pdf /doc forms as and when required. 35

37 vii. All reports to be archived on daily basis for maximum possible days/months (minimum 3 years). Reports to be retrievable /printable with print preview option. Master list of reports and their formats along with samples (if required) shall be decided/supplied by POSOCO during SRS finalization stage Event Log Generation Considering all interactions through software, every user interaction shall be recorded as valid logs under user level and system level as the case may be. Location of log file should be configurable. WBS application should have audit trail through event logging for each and every activities, irrespective of success or failure of the interaction. The system shall provide audit trail of user and system activities that enables data changes to be tracked and reported, including changes made by system administrator. All users of the application including system administrator must have unique IDs. Each time the users log into the application a log with user ID, timestamp and IP-address must be generated. When user makes changes to database either in the form of new data submission or editing existing data, the user shall be prompted to input a reason for the same using either a standard reason code or a freeform text field. In addition to data stored in the edit log each interval containing edited data shall be marked with a status to indicate that data has been edited. Pre-edited value shall be stored in database as a previous version which can be retrieved using as-off date functionality. Changes to configuration data by users shall be logged by timestamp and user ID and such logs shall be stored for a minimum of 12 months. Full data and system audit ability such as version controls and retrieving data according to the date and time should be available Performance Requirement The application software shall be designed as per the technical parameters defined in the specifications and as specified here. The system (such as databases, number of constituents, number of simultaneous users, etc) shall be sized to accommodate expansion. Web servers to be accessed by 100 people simultaneously. User at RLDC/NLDC should be able to view simultaneous number of users logged on to identify limit crossing so as to interpret any user service decline. It shall update at regular time interval as per administrator configured periodicity. The application shall be tested with the ultimate database size i.e. database dimensioned/sized as per the expansion requirement but populated to present system size. 36

38 Performance Requirements (excluding internet communication latency) Item no. Action Description Response time 1 Requests for call-up of user interface 5 sec 2 Application display with data 10 sec 3 Manual Data entry of the new value shall appear on screen 5 sec 4 Response time for display of Alarm and event 5 sec 5 Alarm and event acknowledgement 5 sec 6 Requests for generation of reports shall be acknowledged with an indication of request is being processed 5 sec 7 Report generation 1 minute 8 Failover response time for application server, web-server and database server 2 minutes 9 Logical checks and balances and associated computations 15 sec 10 Data import/transfer 5 sec Utilisation Processor Utilization Average Utilisation Comments Web Server (Application) Data Server 25% 50% 25% 50% Normal loading (upto 10 users) Peak loading (more than 20 users) Normal loading (upto 10 users) Peak loading (more than 20 users) The performance specified here are the maximum times required of the user interface during normal and peak loading conditions. Averaged or other statistically processed response and update times will not be acceptable. Response rate mentioned in specifications shall be maintained for all the application software. The performance analysis shall be part of the Technical proposal in the bid. An updated performance analysis to reconfirm the ability of each system to meet employer s performance requirements will be submitted by the bidder after completion of detailed system design. Failure to meet the performance criteria shall require the bidder to provide all necessary software modifications and additions until the performance criteria are satisfied. 37

39 2.13 Bill of Quantity(BOQ) I ERLDC Location: Kolkata Item no. Description Quantity Unit Remarks Apportioned %age X Project Price 1 Lot Supply 1a. Web Based Energy scheduling software with associated configuration 1 Lot 50 1b. Source code (optional) in CD 1 Lot Not included for bid evaluation 2. Installation of 1a 1 Lot Training 1 Lot Lot means 3(Three) training modules mentioned in Section - 3 Included in 2 4. Warranty 1 Year 0 Y AMC Price 1 Lot Maintenance (After expiry of warranty period) 5a. Annual Maintenance(AMC) 3 Year 3X10=30 5b. Annual Maintenance(AMC) 1(optional) Year Not included for bid evaluation II NERLDC Location: Shillong Item no. Description Quantity Unit Remarks X Project Price 1 Lot Supply 1a. Web Based Energy scheduling software with associated configuration 1 Lot 50 38

40 1b. Source code (optional) in CD 1 Lot Not included for bid evaluation 2. Installation of 1a 1 Lot Training 1 Lot Lot means 3(Three) training modules mentioned in Section - 3 Included in 2 4. Warranty 1 Year 0 Y AMC Price 1 Lot Maintenance (After expiry of warranty period) 5a. 5b. III NRLDC Item no. Annual Maintenance(AMC) Annual Maintenance(AMC) 3 Year 1(optional) Year Not included for bid evaluation Description Quantity Unit Remarks 3X10=30 Location: Delhi X Project Price 1 Lot Supply 1a. Web Based Energy scheduling software with associated configuration 1 Lot 50 1b. Source code (optional) in CD 1 Lot Not included for bid evaluation 2. Installation of 1a 1 Lot Training 1 Lot Lot means 3(Three) training modules mentioned in Section 3 Included in 2 4. Warranty 1 Year 0 Y AMC Price 1 Lot Maintenance (After expiry of warranty period) 5a. Annual Maintenance(AMC) 3 Year 3X10=30 39

41 5b. Annual Maintenance(AMC) 1(optional) Year Not included for bid evaluation IV SRLDC Location: Bangalore Item no. Description Quantity Unit Remarks X Project Price 1 Lot Supply 1a. Web Based Energy scheduling software with associated configuration 1 Lot 50 1b. Source code (optional) in CD 1 Lot Not included for bid evaluation 2. Installation of 1a 1 Lot Training 1 Lot Lot means 3(Three) training modules mentioned in Section 3 Included in 2 4. Warranty 1 Year 0 Y AMC Price 1 Lot Maintenance (After expiry of warranty period) 5a. Annual Maintenance(AMC) 3 Year 3X10=30 5b. Annual Maintenance(AMC) 1(optional) Year Not included for bid evaluation V WRLDC Location: Mumbai Item no. Description Quantity Unit Remarks X Project Price 1 Lot Supply 1a. Web Based Energy scheduling software 1 Lot 50 40

42 1b. with associated configuration Source code (optional) in CD 1 Lot Not included for bid evaluation 2. Installation of 1a 1 Lot Training 1 Lot Lot means 3(Three) training modules mentioned in Section 3 Included in 2 4. Warranty 1 Year 0 Y AMC Price 1 Lot Maintenance (After expiry of warranty period) 5a. 5b. Annual Maintenance(AMC) Annual Maintenance(AMC) 3 Year 1(optional) Year Not included for bid evaluation 3X10=30 VI NLDC Location: Delhi Item no. Description Quantity Unit Remarks X Project Price 1 Lot Supply 1a. 1b. Web Based Energy scheduling software with associated configuration Source code (optional) in CD 1 Lot 1 Lot Not included for bid evaluation 2. Installation of 1a 1 Lot Training 1 Lot Lot means 3(Three) training modules mentioned in Section Included in 2 4. Warranty 1 Year 0 Y AMC Price 1 Lot Maintenance (After expiry of warranty period) 41

43 5a. Annual Maintenance(AMC) 3 Year 3X10=30 5b. Annual Maintenance(AMC) 1(optional) Year Not included for bid evaluation Please refer payment terms mentioned in GCC Section IV clause C - Payments and also detailed in Section VI Sample Forms and Procedures (Appendix-I) of Volume I End of Section

44 SECTION-3 TESTING 3.1 General The scope of the project shall include appropriate provisions for testing of the application software as mentioned in the specifications. 3.2 Factory Acceptance Test (FAT) There would be Factory Acceptance Test on simulated data at bidder s premise. Successful bidder would offer for Factory Acceptable Test to the employer or their representative after software development is completed. The test procedure would be jointly approved by employer and bidder during document preparation to test the software module for proper functioning. Employer would depute their representative to witness the FAT. Delivery of the software would be allowed only on successful FAT tests. 3.3 Site Acceptance Test (SAT) There would be Site Acceptance Test at the employer place with actual field data and the same would be carried out in the presence of bidder and employer s representative. SAT tests would be subset of FAT test jointly decided by bidder and employer during documentation. 3.4 Availability Test. There would be 7 days availability test with availability criterion of 99.9% after completion of SAT. The availability calculation would be as per methodology mentioned in Section 5.5. This would be carried out after complete migration to new software and bidder would ensure availability of their representative at the employer location during the same. Operational Acceptance Certificate (OAC) shall be issued on successful completion of availability test End of Section

45 4.1 Training SECTION 4 TRAINING AND DOCUMENTATION The scope of the project shall include 3 (Three) training modules at each RLDC/NLDC for (i) 5 persons (ii) 12 persons and (iii) 30 persons in 2 batches. Training shall be planned in different level & conducted by bidders personal who are experienced instructor. All necessary training material shall be provided by the bidder. Each trainee shall receive individual copies of all technical manuals and all other documents used for training. The training courses, and their duration in each courses are identified in Table-1 Table-1: Training Requirements per Location S.No Training Course Total No. Participation of days 1 System Administration Level 2 Expert Level, persons responsible for system maintenance 2 Scheduling Preparation Level 2 Shift Engineers responsible for carrying out scheduling at RLDCs/NLDC 3 User Level for States, Generators and others users 2 Person using the system for user input, view data and similar applications 4.2 Documentation Complete documentation is required to support system setup, operation and maintenance. All documentation shall be delivered in both electronic format (e.g. PDF, MS WORD, Hypertext, etc.) on CDs/DVDs/USB drive and in hardcopy format. Sufficient on-line documentation, such as help screens, user guidance messages, context-sensitive help information links etc., shall be included with the system to minimize the need for users to consult the hardcopy documentation. The documentation shall include following but not limited to: i. Procedures for final system setup and use with regards to all features. ii. iii. iv. Documentation of procedures regarding routine maintenance including use of system diagnostics. Detailed flow chart diagrams indicating inter-connection of data flow. A complete copy of Energy Scheduling functional design v. Details of Energy Scheduling database. vi. vii. Procedure of report generation General trouble shoot checks End of Section

46 SECTION 5 MAINTENANCE 5.1 General Scope of work consists of Comprehensive Preventive and break down maintenance of the web based application software including database supplied under the contract during one year warranty period and three year maintenance period thereafter. Moreover, there shall be provision (optional) for one year additional maintenance. 5.2 Resolution Time Schedule Applicable at field locations (RLDCs and NLDC) Preventive maintenance shall consists of measures regarded as necessary to maintain the software in proper functional condition as per the performance requirements and shall be executed once every quarter at mutually agreed dates. Preventive maintenance includes but not limited to functional checking, software updation, taking backup of the database for secure archiving and restoration (if required) and necessary repair/replacements/ adjustments etc. Preventive maintenance shall ensure functional and modular integrity of the application Break down maintenance is to be carried out in the event of malfunctioning of webenabled scheduling software, which prevents timely scheduling and related activities of RLDCs/NLDC. Break down maintenance includes fault finding, repair or replacement of software modules/ components, functional checking, Analysis of the fault and plan for preventive measure to arrest recurrence of such faults, if any. Immediately on noticing the fault, the fault will be reported by the Employer/ Owner on phone to the bidder. The fault reporting time on phone shall be taken as reference time for the purpose of Response Time (RT) and Turn Around Time (TAT). Efficient, reliable, responsive and effective services with minimum Response Time (RT) and Turn Around Time (TAT) shall be the essence of the maintenance services to ensure proper functioning of the application software. RT is response time when bidder s person responds after reporting of fault in system. TAT is Turn-around-time when system is brought back in service after necessary rectification works. During normal hours (0900 to 1800 hrs) maximum RT of 30 minutes shall commence after logging complaint with the bidder whereas if complaint is logged after 1800 hrs, maximum response time of 60 minutes shall be allowed. For remote support, TAT shall be 30 minutes in both circumstances and shall start after remote access is given to the contractor for working on the system. In case resolution of the complaint requires physical presence of the bidder s representative at concerned location then TAT shall be 2 (two) hours starting from the time the maintenance person(s) report to the concerned location. 45

47 5.3 Scope of Work for Maintenance The scope of maintenance services to be provided by the bidder will include but will not be limited to the following: (i) Bidder shall be responsible for providing "Maintenance" of the system under warranty for a period of one year for ensuring the successful operation of the system. The maintenance period shall be 3 + 1(optional) years at the price agreed in the final offer of the bidder & same terms and conditions. (ii) During the warranty and AMC period, the bidder shall have prime maintenance responsibility for the system including database through remote support in normal case. However in case of necessity bidder has to depute the person to the site for attending the faults which is not possible through remote support (actual travel time will be allowed in such cases). (iii) Bidder shall document the maintenance activities to be carried out and shall establish a maintenance record for the performance of their duties and location wise history record of the equipment for future reference. (iv) Bidder s services must be available on phone or fax round the clock on all working days/holidays for fault reporting and corrective actions. (v) Bidder will take all due necessary safety precautions for proper safety of man & machine while carrying out the work at site. Employer/ Owner shall have no responsibility whatsoever for claims arising out of negligence/accident or any other reason for the personnel employed by the bidder. (vi) Bidder or his representative shall prepare and furnish a detailed account of the maintenance work performed and present it to the employer/owner for office record after resolution of the complaint. The same shall be duly acknowledged by the employer/owner. 5.4 Modifications during Warranty / Maintenance period Due to changes in the principle regulations, etc as per notifications and orders passed by CERC from time to time, there may be requirement for carrying out major changes on the Energy Scheduling software including database. In such cases, bidder would employ their expert for implementation of the software changes on chargeable ` 5000/- (Rupees five thousand only) per man day, in addition to their travel and lodging arranged by owner (here respective RLDC/NLDC). The bidder is also encouraged to carry out the software modification at their works in which case the charges for the software changes would be applicable for 5 days or actual number of days (whichever is minimum) for each individual instance (based on official communication/letter from user for carrying out the modifications) as per the documentation submitted by the bidder giving all details connected with work performed and duly certified by the respective RLDC/NLDC Engineer In-charge. 46

48 5.5 Availability of Application Software Bidder shall provide a guaranteed availability of 98% for the application software during warranty and AMC period. The availability calculation commences effective from the end of the allowed Turn Around Time (TAT). Bidder will ensure availability of the supplied application software as per specifications and also maintain the same during the entire period of contract including optional AMC of one year. The availability calculation mentioned herein is applicable for payment purpose during warranty and AMC period. The down time is calculated after expiry of Response Time and Turn Around Time. Item no. 1 Description Application software (including database, functional modules, user interface, etc) Availability (%age) >=98 Availability shall be calculated for each RLDCs and NLDC where bidder s software is installed as under Availability(%) = Total hour in a calculation time period Total down time X 100 Total hour in a calculation time period End of Section

49 SECTION 6 SOFTWARE CUSTOMIZATION 6.1 RLDCs/NLDC specific customization In view of the different approaches existing across the RLDCs, there may be requirement of specific functions, tools, input/output formats, etc. Such specific requirements should be addressed by the RLDCs individually under customization scope. Special requirement for WRLDC There are ISGS having units with multiple fuels resulting in significant price difference for the requisitioned power. Under such cases some of the beneficiaries do not opt for high cost power. This poses complexity in treatment of URS, scheduling and unit commitment. These complexities are usually encountered during the scheduling of Kawas and Gandhar generating stations. Further, schedules have to be submitted to WRPC in pre-defined formats which have to be addressed under report generation. Though over-all business logic, evolved from IEGC, is uniform across all RLDCs certain minor RLDC specific requirements may exist at other locations which shall be addressed mutually by the vendor and concerned RLDC(s) under the scope of software customization. Details in this regard and in connection with other such minor modifications (if any) shall be arrived in post award discussion during preparation of (Software Requirement Specifications) SRS. Modifications under the scope of customization shall not involve any structural changes in database End of Section

50 Annexure I System Architecture Application software NLDC USER1 ISGS WWW Network SLDCs Windows Clustering Web Server 1 Web Server 2 USER2 Local Area Network (LAN) IPP Router + Firewall UTC reference time Oracle Server 1 Oracle Server 2 LASER PRINTER RAC Clustering WORKSTATION 1 WORKSTATION 2 DATA STORAGE SYSTEM ARCHITECTURE Data 49