Pseudo-regulation F: EDI communication in the electricity market March Version Slettet: June.

Transcription

1 Pseudo-regulation F: EDI communication in the electricity market March 2011 Version 2.0 Slettet: June Slettet: 0 Slettet: DATE BOO MBN JHH NAME DATE CCO JHH NAME REV. DESCRIPTION PREPARED CHECKED REVIEWED APPROVED Energinet.dk DOC. NO.

2 Preface General This pseudo-regulation is part of the set of documents describing the market rules to apply when the DataHub is activated in the Danish electricity market in April The new market rules focus on aspects that will change with the implementation of the DataHub. Some aspects may therefore not have been described yet, and in that case, we refer to the current regulations. The pseudo-regulations are the result of the work undertaken by various subproject groups, and the rules described have been considered and discussed by the players involved in the Energinet.dk project. Pseudo-regulation indicates that the market rules have not yet been submitted for consultation and have not gone through the approval procedure of the Danish Energy Regulatory Authority. The contents of the pseudoregulation are therefore not legally binding and may be changed until the date when the regulation comes into force as part of Energinet.dk s market regulations. However, Energinet.dk does not expect such changes to be very extensive or have any bearing on the fundamental elements of the pseudoregulation. The regulations are published at this early stage to give the players the opportunity to prepare the implementation of the rules relating to the DataHub activation. The full set of pseudo-regulations and related documents are available at Feltkode ændret Slettet:.dk The set of documents is also part of Energinet.dk's tender material in relation to the DataHub. Specifically for this pseudo-regulation In this version, the pseudo-regulation contains selected sections that have been updated or prepared in respect of the overall DataHub tender documents. The pseudo-regulation describes the most important aspects of the further work towards implementing the DataHub, including the preparation of tender and the adjustment of the players IT systems. - The pseudo-regulation is based on Energinet.dk's regulation F: EDI communication rev., 2 September 2009 Further information and answers to queries can be obtained from Energinet.dk's contact person responsible for Pseudo-regulation F, see Energinet.dk's website at where the latest applicable version of the pseudo-regulation can also be downloaded. Slettet:.dk Formateret: Skriftfarve: Blå Feltkode ændret Doc /10, Case 10/3365 2/24

3 Table of contents 1. Introduction Definitions General provisions Energinet.dk Danish provisions DataHub principles Role of the DataHub in the electricity market Interchange formats Player identification Communication General rules for messages EDIFACT and XML Error handling and acknowledgements Time, date and period formats Opening hours for the DataHub and the player test system Time limits and time indications Identification Use of signs Identification of price areas in the electricity market Rounding rules, digits and decimals IT system errors Communication platform Web services Web-based access Web system for notifications and operational schedules Register of player master data Requirements for players' IT systems Requirements for functionality Player test system...24 Appendix report 1: Syntax and structure of EDIFACT and XML messages Appendix report 2: Principles and rules of acknowledgement Appendix report 3: The Danish role model Appendix report 4: DataHub - web service interface Doc /10, Case 10/3365 3/24

4 1. Introduction This pseudo-regulation describes how the technical data interchange must work once the DataHub is implemented into the Danish electricity market. The pseudo-regulation is accompanied by four supplementary appendix reports specifying the principles and rules. The pseudo-regulation describes the two formats applied in the electricity market (XML and EDIFACT) and how they must be applied in connection with data interchange to/from the DataHub. The objective of the pseudo-regulation is to ensure that all players in the electricity market communicate and exchange data on equal terms. The pseudo-regulation targets players, IT suppliers and other relevant stakeholders participating in or in other ways having relations to electricity market data interchange. The regulation applies technical terms requiring basic technical knowledge about XML and EDIFACT and general knowledge of communication protocols and data interchange. Doc /10, Case 10/3365 4/24

5 2. Definitions APPOINTEE: Party (or parties) entitled to use the metering point - ie is/are entitled to change electricity supplier or report a move-out from the metering point etc. An appointee may be registered either as a legal entity ie an enterprise or other entity with a CVR no. (Central Business Registration Number) or as a private individual. It is the appointee that is registered in the metering point master data in the DataHub. CHANGE OF SUPPLIER: Change of electricity supplier for the metering point in question. CUSTOMER: Party liable for the consumption for the metering point. DATAHUB: An IT-platform owned and operated by Energinet.dk. The DataHub handles metered data, master data, transactions and communication with all players in the Danish electricity market. DEFAULT ELECTRICITY SUPPLIER: Used about a licensed electricity supplier obliged to supply electricity to customers that do not exercise their right to choose another supplier, or if a supply agreement with another supplier has terminated. EFFECTIVE DATE: The effective date and time when a change (change of supplier or move in/move out, for example) is to take place. The time is always at the beginning of the day (at 00.00) on the relevant date. EIC NO.: European Identification Code. ELECTRICITY SUPPLIER (SUPPLIER): A retailer that: 1) sells electricity to end-customers while holding balance responsibility for the metering point. Customer accounts are thus settled on the basis of metered consumption; and 2) has concluded a standard agreement with Energinet.dk on inclusion as electricity supplier in the DataHub. For practical and historical reasons, the term electricity supplier is also used about a player that buys electricity from a producer. GRID AREA: A physically interconnected electricity grid delimited against the adjacent electricity grids with 15/60 meters and owned by the same grid company. GRID COMPANY: Enterprise that has been granted a licence to operate transmission or distribution grids under the Danish Electricity Supply Act and is also responsible for metering. GSRN NO.: Global service relation number. Unique 18-digit identification of a metering point. HOURLY SETTLEMENT: Used for all metering points where the grid company remotereads, validates and distributes 15/60 values on a daily basis and the values are used for balance settlement. Doc /10, Case 10/3365 5/24

6 LOAD-PROFILE SETTLEMENT: Used for all consumption metering points where hourly settlement is not used (see relevant definition). Load-profile settlement involves, for example, metering points read annually by the customer and metering points where hourly values are remote-read on a weekly basis by the grid company without being used for balance settlement. METERING POINT: A physical or defined (virtual) point in the grid where electrical energy is metered, calculated as a function of meter readings or estimated and classified as consumption, production or exchange. A metering point is the smallest unit in the electricity market in connection with the calculation of electrical energy for an end-customer, producer, electricity supplier, BRP or a grid company. MOVE-IN/MOVE-OUT: Change of customer for the metering point in question. REGISTER OF PLAYER MASTER DATA: A register available in the DataHub web portal with various information about each player. WORKING DAY: Working day as defined in Pseudo-regulation D1, Appendix 2. Doc /10, Case 10/3365 6/24

7 3. General provisions This section describes the general provisions for data interchange in the electricity market, including Energinet.dk s role. The section briefly describes market regulations, business processes (see 'Business processes for the Danish electricity market') and business transactions (see 'EDI transactions for the Danish electricity market'). 3.1 Energinet.dk Energinet.dk is responsible for the DataHub, which is expected to be deployed in April The DataHub will give Energinet.dk a more direct role in data interchange since the DataHub will become the central link between the market players. By virtue of its role as transmission system operator (TSO), Energinet.dk participates in a number of international forums with a view to standardising and harmonising data interchange in Europe, something that has had a considerable impact on this pseudo-regulation. 3.2 Danish provisions The international provisions form the basis of the national provisions. The provisions are operationalised through various document levels addressing different areas of the business. To the extent this problem is not described in this pseudo-regulation, reference is made to these Market regulations Based on the Danish Electricity Supply Act and related executive orders, Energinet.dk has drawn up a range of market regulations. The regulations prescribe how all players should act in the electricity market in relation to their individual roles. Regulations constitute the necessary framework to ensure the functioning of the electricity market Business processes (Business Requirement Specifications - BRS) The document 'Business processes for the Danish electricity market' uses process descriptions to describe how the electricity market works as a business. The target group mainly comprises players in the Danish electricity market. The description includes sequence diagrams that illustrate at an overall level how data interchanges between the various players. More, for each process, the document specifies the overall data to be interchanged. The business processes comply with the market regulations. The technical content of the data interchanges is not specified in detail. Reference is made to 'EDI transactions for the Danish electricity market', see chapter This means that the need for new and revised business processes is easier to formulate and implement and that market players will therefore be less tied by technical specifications. Doc /10, Case 10/3365 7/24

8 3.2.3 Business transactions (Requirements Specification Mappings RSM) Business transactions are the technical descriptions of business processes and describe the individual messages included. All current business transactions are collected in 'EDI transactions for the Danish electricity market', which describes the interaction with the underlying applications by means of incident and activity diagrams. The messages included in the process explicitly appear. The class diagrams are logical class diagrams. Under 'EDI transactions for the Danish electricity market', the following technical descriptions are available: - MIGs (Message Implementation Guides) in which the EDIFACT messages used in the electricity market are described - Technical class diagram and XML schemas Coherence between rules The market regulations outline the basic business rules. The rules from the regulations are broken down into individual business processes termed BRS (Business Requirement Specification) 1, and the EDI transactions in the individual business processes are described in the RSM documentation (Requirement Specification Mapping) 2. Slettet: The XML messages applied in the electricity market is described in 'EDI transactions for the Danish electricity market' which integrates the messages. The EDIFACT messages applied in the electricity market is described in independent MIGs (Message Implementation Guides). Markedsforskrift Market regulation Markedsregler Market rules Business Business - processes for for the danske Danish the Danish electricity elmarked market electricity market BRS BRS - Business Requirement Business Requirement Specification Requirement Specification EDI - Transaktioner transactions RSM Requirement Specification Mapping The market players must comply with all rules outlined in the market regulations and 'Business processes for the Danish electricity market'. In case of any discrepancy between the documents, the market regulations shall prevail. 1 See the document 'Business processes for the Danish electricity market' 2 See the document 'EDI transactions for the Danish electricity market' Doc /10, Case 10/3365 8/24

9 4. DataHub principles This section describes the overall principles for communicating with the DataHub. 4.1 Role of the DataHub in the electricity market All players in the electricity market must interchange data direct with the DataHub, and no player is allowed to interchange data direct with other players in terms of messages included in the market regulations for the Danish electricity market. The purpose is to make the DataHub the central hub between players. This is to ensure the quality of communication and ensure a central place for storing data for further use. The DataHub thus takes a central role in communication as it processes and, if necessary, passes on communication in the electricity market. 4.2 Interchange formats The DataHub is tasked with processing the contents of the data interchanged. Data interchange takes place in XML or EDIFACT format via web services. The two interchange formats are used in a structured way to move data from a player to the DataHub or vice-versa. The individual player decides which of the two formats to apply. 4.3 Player identification According to the rule for player identification, one player has one player ID in the form of a GLN number (Global Location Number) or an ENTSO-E EIC number (Energy Identification Code). This identification must be used regardless of the number of roles assumed by a player (see Appendix report 3 'The Danish role model'). The rules for player identification are illustrated in the figure below. Player identification Group 1 * Company 1 1 Player 1 1 Identification / Player ID 1 * Roles The figure applies central terms, which are defined below. Group A general term used if a business undertaking comprises two or more companies. Company A company has a range of legal obligations and a separate CVR no. By virtue of its commercial status, the company is legally responsible for the player s roles. Player A player is responsible for the exchange of EDI or XML messages related to the role. Role The roles a player can assume are defined in the Danish role model. These roles are solely used in the electricity market. Doc /10, Case 10/3365 9/24

10 Player ID The technical identification of a player in the form of a GLN number (Global Location Number) or an ENTSO-E EIC number (Energy Identification Code), see chapter Communication Web services must be used for exchanging EDI messages. Each individual market player has its own queue for messages from the DataHub which is identified by the player's GLN number. Formateret: Skrifttype: Fed Formateret: Overskrift 2;Heading; H2;H21;H24;H25;H26;H211;H241 ;H251, Linjeafstand: enkelt Formateret: Skrifttype: Ikke Fed Before a player can start to exchange messages, it must via its master data indicate how this is to be done. - The player must decide whether to use xml or EDIFACT format - The player must indicate whether it wants to use metering point administrators when sending messages. The player must in such case state name and GLN number for the metering point administrator(s) it wants to use in each grid area. - The player must state whether other players are to receive messages from the DataHub on behalf of the player. If this is the case, the player must state for each RSM, where it is legal to insert a substitute, who is the recipient. Formateret: Skrifttype: Ikke Fed Formateret: Skrifttype: Ikke Fed Formateret: Skrifttype: Ikke Fed Formateret: Skrifttype: Ikke Fed Formateret: Skrifttype: Ikke Fed Formateret: Skrifttype: Ikke Fed Formateret: Indrykning: Venstre: 0 cm, Hængende: 1,5 cm Formateret: Skrifttype: Ikke Fed Reference is made to appendix report 4: DataHub - Web service interface for a detailed description. Doc /10, Case 10/ /24

11 5. General rules for messages This section describes the general rules for messages. 5.1 EDIFACT and XML EDIFACT and XML are the two exchange formats used for transmitting data between a player in the electricity market and the DataHub. Rules and principles for the actual data content, central terms and their understanding are outlined in the following section. The syntax and structure of the two data formats are described in detail in appendix report Error handling and acknowledgements Data interchange uses acknowledgements to obtain knowledge of whether a message has reached its destination correctly and to ensure that the content can be used for further processing. Basically, two types of acknowledgement are applied: - Acknowledgement of receipt: An acknowledgement is issued for the validation of sender/receiver as well as syntax and structure. The acknowledgement may be negative or positive and is always issued. The acknowledgement is issued immediately after a given message has been received. Acknowledgement of receipt is not an EDI message but part of the web service call. - Processability error report: An acknowledgement is issued for a negative validation of actual data content in the messages received. The processability error report is an EDI message and must be issued at least one hour after the original message has been received. If the content of the message received is correct, no processability error report will be issued. The sender will thus always know whether a message has reached its destination and the result of subsequent processing. All provisions relating to use of acknowledgements are specified in Appendix report Time, date and period formats Terms and their use: UTC: Universal Time Coordinated. In practice identical to GMT (Greenwich Mean Time). Local time: Time at the location. UTC + 0 (local time not used) is used for exchanging EDI messages (EDIFACT and XML) in Denmark. All IT systems must be able to handle the receipt of different offsets to UTC. Exception: In EDIFACT, time in the C UNB element is always expressed in local time. Standard time / daylight saving time The same UTC offset is used in the messages all year round. Doc /10, Case 10/ /24

12 UTC+0 Standard time in Denmark Daylight saving time in Denmark Electricity The day runs from to on the following day. Electricity The day runs from to on the following day. Denmark switches to daylight saving time on the last Sunday of March and returns to standard time on the last Sunday of October. The day we move to daylight saving time has 23 hours. The day we return to standard time has 25 hours. Notation and periods All date/time formats are written as follows: Format Syntax Note Example XML YYYY-MM- DDTHH:MMZ EDIFACT CCYYMMDDHH mm Format explanation: "-", ":" and T are separators, and Z specifies no offset to UTC time (UTC- 0). Date/time format appears from the EDIFACT DTM segment (Date/time/period) T23:00Z EDIFACT ZHHMM Offset to UTC time stated in hours Time synchronisation It is a requirement that IT systems generating and processing messages are within 1 minute +/- of local time. 5.4 Opening hours for the DataHub and the player test system Normal operating time The DataHub can normally be used by customers (via the electricity supplier's website) and professional players (grid companies, electricity suppliers, BRPs and brokers) from: on all days of the year The player test system has the same normal operating time. Formateret: Overskrift 2;Heading; H2;H21;H24;H25;H26;H211;H241 ;H251, Linjeafstand: enkelt Formateret: Skrifttype: 9 pkt, Fed, Ikke Kursiv Formateret: Overskrift 3;Sub Head ing;h3;h31;h34;h35;h36;h311;h 341;H351 Energinet.dk will publish statistics of system availability for each calendar month Critical business time and support The critical business time is defined as the time from: to on all working days. Doc /10, Case 10/ /24

13 Energinet.dk's support in the form of the answering of telephones, IT support, business support, fault handling, etc., is only available in the critical business time Uptime expectations Customers and professional players may expect the DataHub to comply with the following requirements for uptime: Period Within critical business time 99.5% Outside critical business time 98.5% Uptime (in relation to normal operating time) Tilgængelig driftstid (timer) Normal driftstid (timer) Uptime is measured as: *100% Uptime means that: - it is possble to implement business processes (BRSs) both via EDI and the web portal - it possible for the electricity suppliers to access the web application from the DataHub (customers' access to own data) - the DataHub can implement necessary calculations and aggregations so that results can be supplied to electricity suppliers and BRPs - the systems comply with the reply time requirements agreed between Energinet.dk and Logica Danmark A/S. Service windows, see chapter 5.4.5, are not included in the calculation of uptime. Similar requirements for uptime apply to the player test system Announcement of downtime If the DataHub or the player test system is out of operation either in full or in part, this will be announced at the portal as soon as possible. If the systems are being subjected to planned service and maintenance, it will be announced at the web portal in sufficient time in accordance with an updated rolling service plan. It will also be announced when the system(s) is/are operational again Service windows A service window is the time when the DataHub or player test system will be out of operation in connection with maintenance and updates. Service windows for the DataHub and the player test system are placed outside the critical business time. IT environment Service window Time of announcement Feltkode ændret Doc /10, Case 10/ /24

14 DataHub 6 hours per month According to plan shown on portal Player test system 8 hours per month According to plan shown on portal Guaranteed reply time requirements for EDI messages and acknowledgements EDI messages initiating a certain business process often requires a replay or new messages (typically within an hour) in the form of an EDI message or content acknowledgement, see pseudo-regulations H1, D1, I or F. For the DataHub and the players communicating with the DataHub via EDI, the following applies: The time requirement for the reply or the submission of a new message, only applies in the critical business time. The clock, which the time requirement is measured against, consequently stands still outside the critical business time, see the following examples where replies must be sent within an hour: - if an EDI message has been received at on a business day, a reply must be sent at on the next working day at the latest - if an EDI message has been received at on any day, a reply must be sent at on the following working day at the latest. According to chapter 5.4.1, the DataHub will normally receive, answer or send messages 'all around the clock on all days of the year', but the guaranteed reply time is calculated in relation to the critical business time. 5.5 Time limits and time indications The purpose of this section is to describe in clear terms how to understand a time limit and how to meet it. A time limit is defined in the market regulation in which the time limit is mentioned. Time limits form part of a number of business processes and are either calculated as the number of working days relative to the expiry of the time limit or as an exact time (absolute time limit). The following conditions are crucial for correctly calculating a given time limit: - A process can be started on any day, but the time is counted within the five working days of the week, see Pseudo-regulation D1. - A time limit based on a number of days means that a given message must reach the recipient a number of working days (full days) before the time limit is reached in order to meet the requirement (relative time limit). - A time limit based on an exact time, for instance Thursday at means that a given message must reach the recipient on or before Doc /10, Case 10/ /24

15 Thursday at 8.59 am in order to meet the requirement (absolute time limit). Doc /10, Case 10/ /24

16 Examples of the use of time limits Determination of time limit based on an absolute time limit Data must be sent within a given time limit. In this example the time limit is Thursday 11 March at am at the latest. Data must be received Thursday 11 March at 9.59 to be in time. Ex. 1 Figure 1: Determination of time limit based on an absolute time limit Ex. 2 Determination of time limit based on date indication A message must be sent not later than four days before the effective date. In this example, the effective date is Friday 12 March. The message must be received on or before Sunday 7 March at to comply with the time limit. Figure 2: Determination of time limit based on date indication Ex. 3 Determination of time limit based on date indication (over the weekend) A message must be sent not later than four days before the effective date. In this example, the effective date is Wednesday 10 March. The message must be received not later than on Wednesday 3 March at to comply with the time limit since the weekend is not considered as working days. Figure 3: Determination of time limit based on date indication (over the weekend) Ex. 4 Determination of effective date back in time A move is reported five days back in time. Today s date is Friday 12 March, am. The effective date for the move is Friday 5 March at Figure 4: Determination of effective date back in time Doc /10, Case 10/ /24

17 5.6 Identification Below follows a description of the identification systems used in the electricity market. A unique identification of players, areas, metering points, etc. is needed Global Location Number (GLN) 3 The GLN number is used to uniquely identify a player. The numbers are globally administered by GS1. In Denmark GLN numbers are allocated by GS1 Denmark and are composed of 13 digits: Positions 1-3: The three first digits are always the prefix (country code), which is 579 in Denmark s case. Positions 3-12: The following positions are allocated consecutively according to the Modulus 10 rules and are administered by GS1. Position 13: The last digit (K) is a check digit calculated on the basis of the preceding characters by means of an algorithm (Modulus 10). The check digit for the GLN number is an integral part of the location number. Example: The sender must make it clear to the recipient that a GLN number be used. This is done by sending code '9' as responsible code organisation in EDIFACT and XML. Slettet: n EIC code is European Identification Code (EIC) 4 The European Identification Code, just like the GLN number, is used to uniquely identify players. EIC numbers are administered by a unit under the ENTSO-E organisation. Moreover, ENTSO-E members benefit from local administrative units that are authorised to issue EIC numbers. Slettet: IC (European Slettet: ) Depending on what the EIC number identifies, different structures have been established. Basically, the number is made up of 16 characters, and the player identification code is structured as follows: Positions 1-2: The two first characters refer to the issuing entity allocated by ENTSO-E. Position 3: The third character is the letter 'X', which indicates that it is a player identification number. Positions 4-15: 12 characters in uppercase letters allocated by the issuing entity. Position 16: Check digit. Example: 11XRWENET The sender must make it clear to the recipient that an EIC code is used. This is done by sending code '305' as responsible code organisation in EDIFACT and XML For further information, see - Doc /10, Case 10/ /24

18 5.6.3 Identification of metering points GSRN (Global Service Relation Number) 5 is a uniquely defined number series allocated by GS1. The number is used as identification in EDI messages. All metering points must be identified by means of the GSRN number, which should be stable over time. It must not be changed in the event of a change of supplier, for instance. The number is for identification only and contains no classification. This means that no information can be derived from the number. Each grid company must acquire a number series uniquely identifying metering points in the grid company s grid area(s). Structure of the 18-digit GSRN no. for all metering points except production metering points Position Example Explanation Pos 1-2: 57 GS1 Denmark. Pos 3-7: (electricity) Pos 8-10: 676 Pos 11-17: XXXXXXX 5 digits fixed for the entire Danish electricity sector for identification of metering points. Number. Pos 18: X Check digit. 7 digits for consecutive numbering of the individual metering points allocated by the grid company. Production metering points are identified by the GSRN number registered for the related electricity-generation facility (plant or wind turbine) in the master data register for electricity-generation facilities. Structure of the 18-digit GSRN no. for production metering points Position Example Explanation Pos 1-2: 57 GS1 Denmark. Pos 3-7: Pos 8-17: XXXXXXXXXX Pos 18: X Check digit Five digits that are predetermined for all Danish electricity-generation facilities either or Assigned upon creation in the master data register. Number uniquely identifying the individual electricity-generation facility. Assigned upon creation in the master data register Identification of grid areas All grid areas have a metering point ID composed of three digits (DE no.) to allow the identification of the area in relevant messages. The DE number is 5 GS1 administers the number series in Denmark. For more information, see - Doc /10, Case 10/ /24

19 allocated by the Danish Energy Association and must be used to identify grid areas. 5.7 Use of signs The following sign convention must be used for communicating metered values: Description Basic (sign rules) Summer (sign rules) Production + + Consumption + + Exchanges + +/- The use of signs is described in more detail in Pseudo-regulation D1. The following sign convention must be used for communicating with Energinet.dk s operational planning system: Description Sign Production in the area + Area consumption - Energy supplied to area, including purchases + Energy out of area, including sales Identification of price areas in the electricity market Denmark is divided into two price areas to which reference can be made in EDI messages, see the table below. Scope Western Denmark (Jutland/Funen) Eastern Denmark: (Zealand and Bornholm) Reference (EIC) 10YDK W 10YDK M 5.9 Rounding rules, digits and decimals Rounding rules The usual rounding rules are applied. Values less than 5 are rounded down, while 5 and above are rounded up. Any residual value resulting from rounding is ignored. Separators and digits Full stop (.) is used as decimal separator. If a decimal separator is included in a value, the separator must be both preceded and followed by at least one digit. For instance, it is not allowed to send (.5) instead it should be 0.5 Decimal separator must only be used as specified in the pseudo-regulations Thousands separator is not allowed A numeric value must not contain special characters. Characters If a value has leading zeros (0), these will not be transmitted Doc /10, Case 10/ /24

20 Leading and trailing blanks will not be transmitted. If, for instance, a field has 20 characters available, but only five characters are used, only the five characters will be transmitted IT system errors If the player experiences operating or system errors with the player or errors in message contents, Energinet.dk must be notified according to the rules outlined on the DataHub web portal. Doc /10, Case 10/ /24

21 6. Communication platform Communication between players and the DataHub takes place by means of electronically specified protocols, depending on the message. The protocols describe how an interchange is to be transmitted from sender to receiver and ensure that the interchanges are intact when they reach the intended receiver. In case of transmission errors, the communication protocols specify how the sender is to be (sender s system). Regardless of transaction type, communication between a player and the DataHub is always initiated by the player. The DataHub serves as a 'queuing system' that saves messages for the player. The player must therefore contact the DataHub regularly and check whether there are any new messages to be retrieved and processed. The following sections describe the protocols applied. 6.1 Web services Energinet.dk s web services are designed to provide the framework for the exchange of messages over the Internet in a secure and reliable manner. The relevant web services target the players in the electricity market who must exchange data with the DataHub. The following terms are used in relation to web services: - Web service: Open standard for data interchange from application to application over the Internet. The service is typically designed to function with a specific interchange type. - SOAP: A protocol for exchanging structured data against a web service. SOAP ensures the data transmission over the HTTP protocol. - WSDL: A structured description of the web service, including data types, details, interface, location and protocols. It also includes information about how to call the web service described. The rules for using the DataHub web services are specified in Appendix report 4. Doc /10, Case 10/ /24

22 7. Web-based access If it proves impossible to send interchanges electronically (EDI messages), it is recommended to conduct the process via the DataHub web portal. 7.1 Web system for notifications and operational schedules As an integral part of Energinet.dk s portal solution, a web-based system for handling notifications and operational schedules has been established in the electricity market (notifications, operational schedules, regulating power bids and regulating power orders). The system enables the players to submit notifications and operational schedules without having access to EDI communication. The purposes of the system are: - to meet the needs of players that find it inexpedient to submit notifications and operational schedules via EDI - to make an alternative form of exchange available to players that are affected by system failures. The players can use the system free of charge. If - against expectations - the system is inaccessible, it is the player s responsibility to find another way of submitting notifications and operational schedules to Energinet.dk. 7.2 Register of player master data Energinet.dk establishes a register of player master data comprising contact information etc. which will be available on the DataHub web portal. Energinet.dk will place the register at the disposal of the players in the electricity market. The register will also be made available to the public at large to the extent that the information is of public interest. The register will also contain corporate information, technical information and any statutory and financial requirements to be met by the players. In the coming register of player master data, the players in the electricity market will be responsible for: - maintaining their own information in the register - keeping abreast of changes made to the register. The players can keep abreast of changes either by subscribing to notifications of changes or by regularly accessing the register of player master data on the DataHub web portal. Doc /10, Case 10/ /24

23 8. Requirements for players' IT systems Energinet.dk has adopted requirements for the IT systems in the electricity market. These requirements are listed on the following pages as requirements for functionality and tests, respectively. 8.1 Requirements for functionality IT systems (communication, applications, etc.) directly or indirectly involved in the exchange of messages with the DataHub must comply with the following requirements: - Systems designed to communicate with foreign players not covered by the Danish rules must be capable of handling other formats and codes (including time zones) than those described in chapter 5. - The systems must provide logging of outgoing and incoming messages to facilitate documentation of all the exchanges that have taken place. The logging must be of such a quality that it is able to contribute to troubleshooting and error correction. - Earlier messages must be retrievable in readable form (ie non-encrypted) as and when needed through an easily accessible user interface. - The systems must store the individual messages or copies of messages in the format in which the messages were originally sent for three years. - The systems must be capable of passing an IT system test as defined by Energinet.dk. A central system will be established with specifications for IT system testing. Until this system has been established, additional information about the test can be obtained by contacting Energinet.dk. - Players must be able to test their systems without this affecting production data. Doc /10, Case 10/ /24

24 9. Player test system To ensure that data can be exchanged with the DataHub, Energinet.dk will establish a player test system to prepare future players for exchanging data with the DataHub. The player test system tests the players message exchange against test cases specifically aimed at the player s role in the electricity market. The player test system can also test the IT systems developed by some of the IT suppliers for the players in the electricity market. Such system test is basically the same as the test aimed at the players, just more comprehensive as the IT systems are tested in respect of all player roles the IT system can be expected to assume. Moreover, the system test also runs though a number of intentionally faulty test cases to ensure that the IT system responds correctly to errors in data communication and/or in the messages. Compliance with the following requirements is a condition for using the DataHub: - All players and IT systems must be approved by the player test system to be authorised to exchange messages with the DataHub. - If a player or IT supplier makes significant changes to the system forming the basis of the exchange of messages with the DataHub, such player or supplier must obtain a new authorisation in the player test system. Figure 5 below illustrates the two test types and the entities tested. Figure 5: Test types the figure illustrates the two test types which the player system must be able to handle. Doc /10, Case 10/ /24