Capacity Auction System Copyright riecado 2007
Contents: 1 General description... 3 2 Functionality... 3 2.1 Overview...3 2.2 Flexibility of the system...4 2.3 Modules and services...4 2.4 Special modules and services...5 2.4.1 Market connector...5 2.4.2 Document Archive...5 2.4.3 Audit Trail...5 2.5 User concept and role management for the auction modules...6 2.5.1 Administrator...6 2.5.2 Auction Office...6 2.5.3 Regulator...6 2.5.4 Transmission System Operator (TSO)...6 2.5.5 Power Exchange...6 2.5.6 Trader...7 2.5.7 Viewer...7 2.5.8 Guest...7 3 Additional information... 7 3.1 User Interface...7 3.1.1 Client software requirements...7 3.1.2 Localisation (National Language Support)...7 3.1.3 Online support...7 3.1.4 Usability...7 4 Services offered by riecado... 8 4.1 Contact Address...8 Table of figures Figure 1: System overview...3 Figure 2: Schematic data flow of the auction calculation core...4 Page 2 / 8
1 General description Capacity Auction System is designed to provide explicit bilateral and multilateral capacity auctions as well as coordinated explicit load-flow based capacity auctions. Further the system has a market coupling module (implicit auctions) included, i.e. it has the possibility to include order books from power exchanges into the clearing procedure. Within the system there are several modules in addition to the different auction modules. Additionally to the modules shown below in Figure 1, there is another module for scheduling support. Although these modules should be seen as an entity, all of them can be run separately. 2 Functionality 2.1 Overview As mentioned above, the software is a highly flexible solution for conducting different types of auctions. Beside different types of capacity and energy auctions, other auctions types like e.g. CO 2 emission auctions can easily be implemented and integrated. The following Figure 1 shows the formerly explained modular concept of the system as well as the relevant internal and external interfaces. Figure 1: System overview Page 3 / 8
2.2 Flexibility of the system One advantage of the system amongst others is the flexibility and the extensibility which is based on the profound modularity of the system. Moreover, the functionality of the auction calculation core is built on a very abstract basis and is detached from any physical product as well. As a consequence, this leads to the potential for an implementation of auctions with products similar to those in the electricity sector, like CO 2 emissions, etc., in an easy way. As shown in Figure 2 the system generates on-the-fly an optimisation model (code) according to the auction definition and its particular input data, like specific auction data, capacities, load-flow data (PTDFs), auctioned products and submitted bids. This model is calculated by high-quality third-party optimisation software and the results are submitted back to system for further processing. Optimisation model Optimisation software (third-party) Mathematical results Optimisation core Capacities, PTDFs, Products, Bids Auction level Accepted bids Configuration, auction data System level Result data, revenues Figure 2: Schematic data flow of the auction calculation core 2.3 Modules and services Hence riecado as an auction provider is able to provide following services, for example: Each type of auction without framework modules, like CRM, billing, etc. Each type of auction including the framework modules, partly or completely. The framework modules are: CRM (Customer Relationship Management) Scheduling Risk management Billing Secondary market Page 4 / 8
Each type of auction means in this context that following attributes can freely be combined: Any product: i.e. any freely definable time period, like yearly, monthly, daily, intraday. Any number of market areas: bilateral, multilateral. Any transportation-cost constraint: i.e. load-flow based, NTC-based. Any auction method: i.e. explicit, implicit, hybrid. Additionally different bid types are implemented, like: Divisible bids Indivisible Bids ( fill-or-kill, all-or-nothing ) Linked bids ( all-or-nothing for a combination of bids) Standard block bids (e.g. base, peak ) Freely definable block bids 2.4 Special modules and services Beside the above described services, three modules with special functionalities are required for a well-working system and are therefore a part of it: 2.4.1 Market connector This module implements the standardised interfaces to the market participants at the following different layers: Transportation layer o Email o HTTP o FTP o Optionally any web services like SOAP, etc. Protocol layer o ESS o ECAN Data format layer o EDIFACT/MSCONS o ESS XML o ECAN XML o Optionally any other file format like CSV, etc. 2.4.2 Document Archive In respect of data transparency, traceability and recovery all system and auction related documents, like any documentations, auction rules, etc., are stored in an archive. 2.4.3 Audit Trail For security issues and system traceability any access is recorded by the system automatically. This includes any authentication attempt and any action of registered users. Adequate tools for statistical analyses, potential error detection and (security) surveillance are integrated into the system. Page 5 / 8
2.5 User concept and role management for the auction modules In accordance with a freely definable user concept and role management the below described roles for the handling of auctions can easily be extended and their rights can be extended or restricted to the needs of the implementation, too. In compliance with the business process needs additional roles for the framework modules should be defined. A detailed description of these possible roles would go beyond the scope of this document, even more as due to the modular concept of the system the services of the framework modules can be provided by third party companies or by already established in-house solutions. Currently following roles, i.e. user types, are defined for the handling of auctions: Administrator Auction Office Regulator TSO Trader Viewer Guest 2.5.1 Administrator Administrators act as the super-users of the system. They are allowed to view, edit and delete everything as well as to run the auctions. Additionally and exclusively they are able to set up system parameters like the creation of new market areas, new interconnections, etc. 2.5.2 Auction Office The role of the Auction Office is mainly defined to coordinate and run auctions and hence they are allowed to fulfil all the tasks connected to it, like the creation new accounts (hierarchically below the level of Auction Office) and new auctions, the publication of the auction results, the initiation of fall-back procedures, etc. 2.5.3 Regulator Regulators are allowed to view all data which they feel relevant to them. The type and amount of data can freely be defined according to the Auction Office s needs and rules. 2.5.4 Transmission System Operator (TSO) TSOs are allowed to view data which are relevant to them. The type and amount of data can freely be defined according to the Auction Office s needs and rules. According to the auction rules exclusive rights can be defined according to the auction rules, like upload of the capacities or loadflow data (PTDFs, i.e. Power Transfer Distribution Factors). 2.5.5 Power Exchange Power Exchanges are allowed to submit anonymous order books to the Auction Office for market coupling purposes. Further Power Exchanges can receive Market Orders due to the market coupling algorithm by the Auction Office and/or the relevant TSO. Page 6 / 8
2.5.6 Trader The role of the trader comprises all rights within the auction rules which are common to every auction. This means that they are able to get any auction relevant data, submit, edit and delete their bids, view their results and the overall (anonymised) results of the auction. 2.5.7 Viewer Viewers are derived from the role of the traders, but they are not allowed to place any bids in the auctions. Thus they have the rights to observe an auction as a passive participant. 2.5.8 Guest Guests comply with the role of an anonymous user which is the ordinary, non-registered visitor. According to the Auction Office needs, members of this role are allowed to view non-sensitive data such as auction results. 3 Additional information 3.1 User Interface 3.1.1 Client software requirements The system is exclusively operated by a web-based graphical user interface (GUI), which implies that there is no need for any installation of proprietary client software but a up-to-date web browser, like MS Internet Explorer 6 or Firefox 1.0 or higher. The support of JavaScript, frames and session cookies are requirements. 3.1.2 Localisation (National Language Support) The system offers a Unicode support (UTF-8) for the display of the texts. All texts used within the system can be translated to different languages. Hence the extension to other languages than English as the predefined language can be done in an easy and efficient manner. 3.1.3 Online support Context-sensitive help is available on each page of the web-based GUI which can be made available in different languages. The predefined language is English. 3.1.4 Usability The user interface is designed according to the currently used and accepted standards for humancomputer-interaction (HCI). Page 7 / 8
4 Services offered by riecado riecado as a auction office service provider can offer the following services: Comprehensive auction software solutions High reliable and high secure hosting of auction software solutions Processing of auctions (front office services) Consultancy services for implementing different types of auctions and power market modeling 4.1 Contact Address riecado Regional Energy Capacity Auction Data Operator GmbH Alserbachstrasse 14-16 1090 Vienna Austria Tel: +43 (0)1 253 7272-92 Fax: +43 (0)1 253 7272-96 http://www.riecado.at Page 8 / 8