Design and Implementation of the Albanian Electricity Balancing Market Dry run trials: High-level objectives and scope Contract no: 7183271 Preliminary Draft, June 13, 2019 Modifed Submitted by: In association with: LDK Consultants Elia Grid International E-Bridge Consulting 1 2 TABLE OF CONTENT 1 OBJECTIVE OF THIS DOCUMENT..............................................................................................................5 2 OBJECTIVES OF THE DRY RUN TRIALS ......................................................................................................6 3 ENTRY CRITERIA OF THE DRY-RUN PHASE ...............................................................................................7 3.1 READINESS OF OST ....................................................................................................................................... 7 3.1.1 Completed project design ............................................................................................................... 7 3.1.2 IT & operational readiness .............................................................................................................. 7 3.1.3 Dry-Run specific entry criteria ......................................................................................................... 7 3.2 READINESS OF THIRD PARTIES........................................................................................................................... 8 4 EXECUTION OF THE DRY-RUN PHASE ......................................................................................................9 4.1 HIGH LEVEL SETUP AND PRINCIPLES OF DRY RUN TEST ......................................................................................... 9 4.1.1 Dry Run Should not influence Real Energy/Money Balances .......................................................... 9 4.1.2 Real, Simulated and Implicit Signals ............................................................................................. 10 4.1.3 Dry Run Should Model all Parties .................................................................................................. 11 4.1.4 Dry Run is a Mock Up including All Subsystems ............................................................................ 11 4.1.5 Automated Coherence between Test and Production System To Be ............................................ 12 4.1.6 Dry run timing and fallback procedures. ....................................................................................... 12 4.1.6.1 Example 1: Bids sent from Market Participants do not reach Market Operator ................................ 12 4.1.6.2 Example 2: Market Infeasibility........................................................................................................... 12 4.2 SUBCOMPONENTS UNDER TEST IN THE DRY RUN ............................................................................................... 13 4.2.1 Qualification (ABM Rules Chapter 7) ............................................................................................ 13 4.2.2 Availability Commitment Process (ABM Rules Chapter 8) ............................................................ 13 4.2.2.1 Participant Registration and mutation process ................................................................................... 13 4.2.2.2 Dimensioning and Sizing ..................................................................................................................... 14 4.2.2.3 Bidding Process ................................................................................................................................... 15 4.2.2.4 Selection Process ................................................................................................................................ 15 4.2.2.5 Pricing ................................................................................................................................................. 15 4.2.2.6 Results Publication .............................................................................................................................. 16 4.2.3 Delivery Commitment Process (ABM Rules Chapter 9) ................................................................. 16 4.2.3.1 Bid Specification.................................................................................................................................. 16 4.2.3.2 Bidding Gate Closures ......................................................................................................................... 16 4.2.3.3 Results Publication .............................................................................................................................. 16 4.2.4 Activation Process (ABM Rules Chapter 10) .................................................................................. 18 4.2.4.1 FCR ...................................................................................................................................................... 18 3 4.2.4.2 aFRR/mFRR ......................................................................................................................................... 18 4.2.5 Invoicing and Settlement for BSP (ABM Rules Chapter 11) ........................................................... 19 5 EXIT CRITERIA OF THE DRY-RUN PHASE ................................................................................................21 4 1 OBJECTIVE OF THIS DOCUMENT We describe in this document the high-level objectives, scope and processes of the Dry Run phase of the ABM project, which is defined as the last phase preceding ABM go-life during which ABM is run in parallel to the current balancing mechanisms. The document starts by explaining why a dry-run phase is desired, and what are the objectives pursued. The following section lists the minimum elements that need to be in place for such a dry-run phase to commence. The document then describes the processes of the Dry-Run phase. Emphasis is put on the differences between the execution of the Dry-Run (i.e. the non-applicability of the results), compared to the period after go-life. The document finishes with some proposals of success factors / exit criteria for the Dry-Run phase, i.e. a list of criteria that needs to be met to complete the Dry-Run phase. Importantly, the processes of the Dry-Run phase should be detailed in light of the global ABM project management approach. As the detailed project management information is not available to the authors of this document, OST should convert the high-level recommendations provided here into a detailed and formal project management documentation. 5 2 OBJECTIVES OF THE DRY RUN TRIALS Dry Run Trials – also sometimes called “Parallel Runs� or “Market Simulations� – simulate the Albanian Balancing Market (ABM) under “actual and real conditions�. In essence they consist of running all the daily processes “as if ABM was live�, except that the (1) physical and (2) financial results are not applied (i.e. (1) actual energy remains managed via the current approach, respectively (2) current financial settlement processes are kept). The objectives of Dry Run Trials are multiple. A key element is to provide a preliminary idea of the market impacts of the ABM mechanism, and in particular whether the prices resulting from ABM are conform with expectations – or the other way around – what are the prices that are expected to come out of the new mechanism. This allows to quantitatively and qualitatively comfort all stakeholders that the ABM mechanism is robust and meaningful. Dry Runs also intent to train all (internal and external) stakeholders so that they get an adequate level of confidence on the ABM mechanism, as well as sufficient acquaintance with the day-to-day business processes prior to the ABM go-life. Dry Runs Trials do not encompass IT or operational testing, which are assumed to be satisfactorily completed prior to the Dry Run Trials phase. Dry Runs nevertheless typically enable to confirm the well-functioning of all IT and business processes in “real conditions� (not only for OST, but also for all relevant involved third parties), and should therefore be seen as an ultimate « feasibility check ». Dry-Runs can also be seen as a set of final checks to identify and mitigate all kind of risks of a go-life failure or roll-back, using a « learning (what can go wrong) by doing (an operational trial) ». 6 3 ENTRY CRITERIA OF THE DRY-RUN PHASE 3.1 Readiness of OST This subsection lists the various areas which need to be in place at OST side (as opposed to what needs to be prepared at the market participants’ side). 3.1.1 Completed project design Entering the Dry-Run phase implies that the design of ABM is finalized, i.e. it should be clear with what operational concept the dry-run will be executed. The concept must abide to the ABM rules submitted for regulatory approval (after consultation). It is however not necessary that these rules are formally approved for the start of the dry-run (they must be formally approved with the start of go-life). 3.1.2 IT & operational readiness Entering the Dry-Run phase implies that the design is fully implemented and operationally ready for go-life at the operator’s side (as described above, Dry-Runs are not about explicit testing). Even if in practice, it is often tolerated to enter the Dry-Run phase while some technical matters remain open due to actual project constraints, this should be seen as the exception – not the rule. All technical and operational tasks required for go-life, except the actual go-life preparation tasks, should be completed before the Dry-Run phase initiation. Therefore, the technical entry criteria of the dry-run phase do by definition encompass the entire exit criteria of the IT and operational testing phases (i.e. all what should be done would no Dry-Run phase exist). Such criteria are typically listed within a “Master Test Plan document�, i.e. a document which list all IT and operational testing strategies and their success criteria. In case exceptions to IT & operational readiness are tolerated, they should be explicitly mentioned. A mitigation plan (that explains the impacts and mitigations measures of each exception during the Dry- Run trials) should be elaborated, and a resolution plan (to resolve the open points before actual go- life) should accompany each exception. 3.1.3 Dry-Run specific entry criteria Separate to the generic technical operational readiness of the ABM, the preparations specific to the dry-run phase should also be ready. In particular, as the Dry-Run phase is not a go-live, the following items needs to be available: • IT and business processes adaptations specific to Dry-Run: these elements are described in Section 4. In a nutshell, they consist of rerouting the physical and financial outcome of the “dry-run ABM� into the ad hoc reporting & publication tools. • Feedback-loop & correction processes: a mechanism should be in place to report and resolve issues arising for any involved parties. This is typically done using a dedicated issue tracking tool (e.g. Jira, https://www.atlassian.com/software/jira), for which access is granted to all (internal and external) individuals involved in the Dry-run phase. • Resume mechanism after dry-run pause: in case – for some reason – the Dry Run phase is paused, there needs to be a process to reactivate the phase. This should include at least 7 factory and non-regression testing, to ensure that an issue resolution always leads to a more stable version. • Validated exit criteria: qualitative and quantitative indicators that define the successful termination of the Dry-Run phase should be set (and formally validated), so that once these indicators are met, ABM can go-life. A preliminary sketch of such criteria is provided in Section 5. • Buy-in of external stakeholders: As external parties are involved in the Dry-Run phase, relevant agreements need to be in place to ensure the adequate involvement of external parties in the Dry-Run phase (see below). 3.2 Readiness of third parties The Dry Run process and its goals should be described in advance and communicated with all stakeholders. The “buy-in� of external stakeholders is a key success factor of a Dry-Run phase. This is in particular the case for market participants, who should “play the ABM game� as if ABM was life, although it isn’t. In other words, although the results of the ABM market will not be executed, it is nevertheless required from all participants to act in good faith and under realistic conditions. Prior to the Dry-Run phase, market participants should be operationally ready to submit all relevant data (i.e. bids) to the ABM systems1. This implies that market participants have been duly informed of the ABM processes and had completed their internal IT and operational adaptations to cope. In particular, this implies that BRPs/BPSs should have gone through an IT testing facility that has proven they can send, receive and process the appropriate communication messages properly. External IT integration testing should also prove the well-functioning of IT communications between OST and market participants before the Dry-Run trials can commence. Importantly, it is expected that the data provided by market participants are representative of their actual situation, because the ABM dry-run outcome (i.e. prices and volumes in particular) are of high relevance during such a Dry-Run phase. 1 Ideally, market participants should also be ready to process the ABM output, although this is not necessary for a Dry-Run phase as these outputs will not be applied « for real ». 8 4 EXECUTION OF THE DRY-RUN PHASE 4.1 High Level Setup and Principles of Dry Run Test The reasoning behind what one should do in a dry run goes as follows. A dry run is intended to simulate a wet run. The difference is that we keep ‘dry’ the connections to other real systems that must not be disturbed. So we try to simulate a maximum of components and communications between these components without such disturbance. This means that we look at a description of sub-components, processes and communications in the real systems, the ABM Rules document and then ’map’ these to their dry run variants. Some real communications or ‘signals’ will then become virtual ones, just present in as signals in simulation that just record this information or send this information to a ‘stub’ block. We give a visual description of a dry run at the most high level possible in Figure 1 below. This will be the guideline to enumerate some general dry run principles. Figure 1 High Level Setup of a Dry Run 4.1.1 Dry Run Should not influence Real Energy/Money Balances Firstly, a dry run is by definition not to impact any current operations. This is why it is also called « parallel runs ». 9 Current operations of OST and market participants (e.g. KESH but also others) are continuing without any disturbance from this Dry Run (test). This means that there will be no outputs from the Dry Run going to current operations, otherwise it would be a ‘wet run’. More specifically, actual energy balances and money balances between participating parties are not supposed to be influenced by the dry run. There are however outputs from current operations going to Dry Run processes, as indicated by the dashed lines in Figure 1. Indeed, the dry run uses some network state information (or any other information coming from the real systems in operational mode) in its inputs going towards the new real ABM systems, although in test mode. In particular, for the sake of the simulation, the current ‘imbalance’ and the volumes of activated (fast and slow) balancing energy should be made available in real time to the ABM dry runs. 4.1.2 Real, Simulated and Implicit Signals As mentioned in the section 4.1.1, in a real system, energies and remunerations are actually sent on specific electricity wires respectively bank transfer channels. In a dry run, this is not the case: the Dry- Run should as much as possible replicate all the ABM processes, except the ones actually impacting the grid, any connected assets, or the bank accounts. Therefore simulated or mocked signals between the involved parties will be required. To indicate the difference between a real signals and a simulated signal, we use a full line and a dashed line. Figure 2 indicates this graphically. Figure 2 Read, Simulated and Implicit Signals Figure 2 also shows a third arrow type, the one with a dotted line. This arrow indicates an implicit signal between parties. This has nothing to do with real versus simulated, but will be just present in graphical representations of processes in this document to remind the reader that a ‘commitment’ was made earlier in time and is now valid for the current time. For example, a contract on availability commitment from a market participant to the market operator made months ago, can apply on the 10 current day D. In that case we would draw a signal, on day D, from this market participant to the market operator. This reminds the reader that the contract content applies on this day. However, neither in real, nor in simulated systems a signal is sent on day D. The receiver, the market operator, will just remember in its information system that the contract applies and it will act on that if and when needed. Figure 2 summarizes the 3 signal types and their meaning. These signal types will also be used in the sequence diagram figures in the rest of this document. A concrete illustration can be found in Figure 7. 4.1.3 Dry Run Should Model all Parties As for the communication between OST and market participants, in Figure 1, we show the information exchange at the highest conceptual level. OST will request energy to e.g. KESH and KESH will deliver that energy, in principle. KESH will send an invoice and OST will pay for this.2 It is of course strongly advised to enroll multiple bidders who are bidding at the same time, in order to simulate a competitive Balancing market. This is necessary, to obtain more credible prices, as well as to test/trigger for example the DAMAS functionality of aggregation of curves in DAMAS and the correct communication back to the different correct bidders in terms of their activated bid (proportions), their pseudo (no) energy, pseudo (no) payment. What is meant with ‘pseudo / no’ parts here is explained in more detail the next paragraph. 4.1.4 Dry Run is a Mock Up including All Subsystems A dry run is to test as many processes as possible, from different angles (market mechanism, IT, operations, …) without affecting systems running in production, so ideally all information regarding also energy delivery and settlement has to be communicated as they would be communicated in the real system under real conditions. Of course, from the dry run no real energy will be delivered and so, also no real payments will be required for example from OST to KESH. However, it is advised to ‘mock’ these processes to the extent realistically possible. This means that the information flow in DAMAS and OST systems around it should register these information flows ‘as if they were real’. Conceptually and in practice, this can for example be done with a field indicating that this is not real but test data. As some point in the information flow, this will then make that no real energy is requested nor delivered and that no real money is requested nor paid. But this ‘mock data’ can be tracked in all sub- systems (e.g. not only DAMAS level but also the SCADA level) as if it is real and as such it can be said that in the dry test, the real systems are tested. More specifically, OST communicated to consultants that they have a ‘mock system’, which can be considered a copy, clone or second instance of the real production system to be. In this case, this corresponds to a system communicating with the outside world via another IP address and/or another port (e.g.: http://test.mms-ost.al/Cfrm.asp, which seems to be a DAMAS instance). 2 OST could send an invoice (actually credit note) for a negative amount of money to KESH and then OST needs to pay KESH, but these are details at this point. 11 4.1.5 Automated Coherence between Test and Production System To Be A separate mock up instance is fine, but of course, great care has to be taken that when adaptations in this system under test are made, they are also made in the real system. Ideally, to ensure that this is really the case, a system to ensure that any adaptation made in the system under test is also automatically applied on the real production-system-to-be is strongly recommended. As an example, for software development, a common repository where both real system (production) and test system (test, release) is an example of this automation. It is not clear to consultants that such automation of coherency exists for DAMAS (for example for all its configuration data), but this is an important point for the dry run setup. 4.1.6 Dry run timing and fallback procedures. In general, it is possible that some sub-processes that are part of the system, in real operations, do not complete successfully. They can either end prematurely or run too slow so that they don’t reach their end goal in time. Running forever is just a special case of this. These processes deadlines are applicable to real time operations. For the dry run, the order of processes should stay the same but they may be executed in an accelerated fashion in order to restrict the time spent in dry run or/and be able to execute these processes more often than in real time to get wider test coverage via more test scenarios. In a dry run, these problems also need to be simulated (although they typically often happen anyway at the early stage of dry-runs), so that the fall back plan including replacement processes can be triggered. This means someone will be responsible to insert or simulate technical error in a subprocess and other personnel will be responsible to detect and address the technical error. Documentation (i.e. fallback and back-up procedures) to ease these tasks will have to be composed. This documentation can be compared to what pilots of planes have in order to quickly find solutions to problems. Basically this ‘book of procedures’ is a list of things that can go wrong (symptoms) and corresponding remedies or/and fall back procedures. For this, training will be necessary, like training plane pilots in simulators is necessary. From this training, the result should be that also in real operations (i.e. under real pressure) people are confident and capable to perform these tasks. 4.1.6.1 Example 1: Bids sent from Market Participants do not reach Market Operator A dedicated electronic channel is used for communication of bids from market participant to market operator. However, if for some technical reason (that should be simulated during Dry-run) this module does not work, then fall back communications mechanisms should be in place (e.g. cascading of ftp, email, fax or phone) h. 4.1.6.2 Example 2: Market Infeasibility In case of market infeasibility, or when the market fail due to other technical (hardware or/and software) reasons, the ABM rules mention various fall back options like, increasing the budget limit, relying more on free bids, engage with neighboring TSOs on cross border reserve sharing, engage with demand side response, sending requests for more bids in a second round of the same auction. This section 4.1 discussed the general setup and some general principles of any dry run, and lean on the pre-existence of a set of fallback procedures. 12 The next section goes more into detail on the setup and principles of a dry run specifically for balancing market and this at the level of its different subcomponents. For each subcomponent a sequence diagram of the process is given, in which real, simulated and implicit communication signals between parties are distinguished. 4.2 Subcomponents under Test in the Dry Run Because all subprocesses in a balancing market require specific things to be tested and checked, we discuss all subprocesses in sequence here. The order of section here is exactly as in the ABM rules document; chapters 7: Qualification, 8: availability commitment, 9: delivery commitment, 10: Activation processes, 11: Invoicing and Settlement for BSP. 4.2.1 Qualification (ABM Rules Chapter 7) We exclude the qualification process since it is a non-critical process from an operational perspective. 4.2.2 Availability Commitment Process (ABM Rules Chapter 8) 4.2.2.1 Participant Registration and mutation process The process for registration and mutation to a qualified BSP is as given in Figure 3. Given that availability commitment processes are not a daily recurring process, the frequency at which such processes are tested might be adapted (compared to the expected operational calendar) in order to trigger sufficient occurrences of running these processes. Figure 3 Market Participant Registration and Mutation 13 The Balancing market operator publishes a tender to its publishing platform (likely a website). Invitations can for example be sent to a list of known interested parties because they participated in tenders in the past. But they can also go to a list of parties that the market operator thinks are potential market participants. Next, market participants can show their interest or not to participate in the tender. Whether the potential market participant is already a qualified BSP or not, it can send its expression of interest (EOI). In case it is not a qualified BSP yet, some extra information needs to be added. (See the ABM rules document for more detailed information.) Note that Figure 3 shows the EOI to be filled for mutation as a separate step before the EOI to be filled for participation, but these EOIs can be part of a single submission as well. Upon receiving the EOI, the market operator decides if the EOI is complete and in case it is, responds with an invitation to the market tendered. In case the EOI is incomplete, the market operator also needs to send a signal to the concerning market participant that the EOI is incomplete and needs to be refilled and resent for the market participant to be given access to the tendered market. This is indicated by the curved, upwards dotted arrows in Figure 3. To be tested in the dry run for this part, as for any part, is that the whole sequence diagram can be run through and that all real and simulated signals are generated and are also received on the other side. Also interpretation of signal content should be the same on both sides. These are the general principles for a dry run of any system. This is a non-exhaustive list of items that will be comforted by the dry-run trial: 1. General requirements: every signal should be sent and received and contents should be interpreted in the same way. 2. Is the tender published on time? 3. Are invitations sent and did they arrive to list of known interested parties? 4. Is published tender accessible from outside market operator premises? 5. Does a properly completed EOI for BSP qualification lead to mutation of the party to qualified BSP and to notification of that fact to the market participant? 6. Does a non-complete or improperly completed EOI for BSP qualification indeed not lead to registration of the party as qualified BSP and to notification of that fact (including more details on the wrongly filled fields) to the market participant? 7. Does a properly completed EOI by a qualified BSP for acceptance to the tendered market lead to acceptance of the (correct) market participant to the tendered market? 8. Does an non-complete improperly completed EOI by a qualified BSP for acceptance to the tendered market indeed not lead to acceptance of the (correct) market participant to the tendered market and to notification of that fact (including more details on the wrongly filled fields) to the market participant? 4.2.2.2 Dimensioning and Sizing Since the sequence of communication is restricted to calculation and publication, we do not need a sequence diagram here to be able to formulate what has to be simulated and tested. As an example, we discuss dry run processes, or here rather things to check, for FCR only. This is a non-exhaustive list of items that will be comforted by the dry-run trial: 14 1. General requirements: every signal should be sent and received and contents should be interpreted in the same way. 2. For FCR, dimensioning should be done at least once a year. This means in the dry run that process should be successfully performed at least once. 3. The resulting amount should be published. 4. For more information, the ABM Rules document can be consulted. For a complete list of requirements, that in principle should all be checked during Dry Run, we refer the reader to ENTSO-E, Operational Handbook CD, Policy 1. For aFFR, mFFR, RR and Emergency Reserves, similar rules hold. 4.2.2.3 Bidding Process 4.2.2.4 Selection Process 4.2.2.5 Pricing We consider the bidding and selection and pricing process together here. Together, they are again a multi-step process, and worthwhile to picture. This is done Figure 4. Figure 4 Bidding and Selection Process Market participants send their bids to the market operator. This contains the amount of MW and bid price in EUR/MW and whether they bid for FCR, aFFR or mFRR. The bid also mentions their identity as well as the availability period. After gate closure, the market operator clears the market, meaning the most interesting bids are selected in merit order, up to a predetermined volume and budget. If the budget is not sufficient to reach the required volume, the budget can in some cases be raised. If the budget cannot be raised further and required volume is still not reached, either a new tender for other availability periods can be made and new bids can then enter the selection process. After the market is cleared successfully, 15 a signal is sent back from market operator to market participant mentioning the bids that are accepted, to which degree (partial or total) and also the bids that were rejected. Note that Figure 4 still implicitly allows for auction failure since it is not guaranteed that even with bids for not the full period or/and voluntary bids, the required volume can be matched by the bids. In that case there is a fallback process as described in section Error! Reference source not found.. This is a non-exhaustive list of items that will be comforted by the dry-run trial: 1. General requirements: every signal should be sent and received and contents should be interpreted in the same way. 2. Are all bids that are sent by the market participants also received by the market operator? 3. Are all bids received outside the allowed interval between gate opening and gate closing (time rule) rejected by the market operator? 4. Are there reasonable and applicable processes foreseen to mitigate the lack of sufficient bids (e.g. due to late submission)? 5. Are bidders correctly notified of (any case of) rejection. Is the reason of rejection also mentioned in this notification? Reasons may be that the bid format is not correct (time rule w.r.t. gate closure, volume rule, price rule) in which case it is best to respond immediately after the bid is submitted. When the reason is that the bid is out of the money, this notification of rejection is of course only be sent back after market clearing. 6. In the case of partial or total acceptance of a bid, a notification needs to be sent back to the bid issuer. 7. Is the total accepted quantity equal to volume required by OST. 8. Are bids selected in merit order? Do market parties understand what the prices are? 9. Are prices entered in the bids in a dry run supposed to be reasonable prices, in the sense that they could occur in reality? 4.2.2.6 Results Publication Before the delivery commitment starts, results to be published are: product requested, total volume offered, lowest and highest bid price, total volume awarded, volume weighted average bid price of awarded volume, highest bid price of awarded volume. This is a non-exhaustive list of items that will be comforted by the dry-run trial: 1. Are the above outcomes all published in due time? 2. Given the reasonable input bid prices and required volumes, are the outcomes in sensible ranges? 3. Is the entire chain realistic from an operational perspective? 4.2.3 Delivery Commitment Process (ABM Rules Chapter 9) 4.2.3.1 Bid Specification 4.2.3.2 Bidding Gate Closures 4.2.3.3 Results Publication The bid specification, bidding gate closures and results publication are taken together and represented as a sequence diagram in Error! Reference source not found.. 16 Figure 5 Delivery Commitment: Bid Specification, Gate Closures, Results Publication Starting at the top of this figure, long before any ISP and bid emission from any market participant (BRP) to Market Operator occurs, the BRP needs to know the format the bids should respect. Any party with access to this platform can then at any time read this specification. Of course a message from market operator to known/potentially interested parties (BRPs) can be sent out to these parties additionally, mentioning the (changed) description is available online. At OST, DAMAS seems to already emit this bid structure specification. Bids can be for balancing (contracted or uncontracted aFRR or mFFR bids). RR Bids for other purposes, e.g. for congestion management, are also possible. All bids have to respect the structure that was communicated to the BRPs before. See the ABM rules document for details of structure and fields of the bid messages. So, bid message should be followed by either an acknowledgement or rejection message sent back from MO to market participant, since this allows the market participant to correct and resend the bid message until it is accepted by the market operator. Going back to Error! Reference source not found., after bid specification publication, then, for all bid messages that relate to ISPs that are part of day D, a daily gate opening at [D-1]:23h and a daily gate closure on [D-1]:23h have to be respected. This means that all bids for the full day of D, have to be received by the market operator in between those two times. These bids are mandatory per BRP. Then, for all bid messages that relate to ISPs that are part of day D, hour h, a gate opening at d-1: 14h:00 and a gate closure on D:ISP start – 1h has to be respected. This means that all bids for the quarter hour of ISP, have to be received by the market operator in between those two times. The ‘hourly’ bid messages are considered to be replacements for the daily bid messages. Hourly bid messages are optional, meaning that if they are not sent, the daily bid messages hold. Both for the daily and for the hourly bid sending protocol, for the respective valid bid messages that were accepted on the market operator side, the following principle regarding bid message resending holds. For each bid message from market participant to market operator, we expect that a confirmation/rejection message is sent back. Any market participant can resend bid messages to the market operator. The market operator will only accept as to be treated final, per market participant, 17 the last message received from it before the gate closure. So any older messages from that market participant will be considered overruled by the newest message before gate closure. Looking back at Error! Reference source not found., one can see that at any time, market participants can request the market operator to show them a bid ladder (also called merit order bid curve) for the next day (so uncleared bids) or for any day before the next day (which will be already cleared, so in addition to the bid ladder which needs to be shown, the clearing point can then also be shown). Note that the bids resulting from both gate closures, daily and hourly, can in general contribute to that merit order bid curve. Per ISP, there are two curves to show, one for up and one for down, or they can be shown together on a positive and a negative quantity axis in one graph. Note that continuously, any market participant can send a bid update, so even if two bid ladder requests are just seconds apart, the resulting merit order curve can be different. This is a non-exhaustive list of items that will be comforted by the dry-run trial: 1. Does DAMAS generate the correct bid format specification? 2. Can this be sent ‘long’ before any ISP occurs? Are the processes realistic operationally? 3. Both for the case of daily and for hourly bid messages: o Does MO send back an acknowledgement/rejection answer on each BRP bid message? o In the case of rejection, does this answer include sufficient detail to allow the BRP to adapt its bids towards the bid specification format? o Are bid messages related to ISPs that arrive after gate closure properly ignored? Are BRPs sent back a rejection answer on these messages? 4. For the daily bid messages, since they are mandatory, (but not for the hourly bids since they are optional), in the specific case where the BRP does not send a bid message for an ISP, does MO send back a message to the BRP mentioning that it did not receive a BRP bid in this ISP, that this is allowed to do so for the BRP, but that this is equivalent to not bidding? This is certainly advisable in the case that the BRP is contractually obliged to send (real) bids. If connection from BRP to Market operator is lost but the connection in the other direction still works, this will be helpful for the BRP to realize the problem and possibly mitigate it in time. 4.2.4 Activation Process (ABM Rules Chapter 10) 4.2.4.1 FCR FCR is continuously activated. The TSO needs to inform FCR BSPs about any change of the target frequency so that they can set their primary controllers accordingly. This two-step interaction is simple enough to not need a sequence diagram. 4.2.4.2 aFRR/mFRR The steps for the TSO to undertake in activation of BSP aFRR and mFRR bids are given in Figure 6. 18 Figure 6 Activation of aFRR and mFRR bids They are for the TSO to nomination bids, where only entire bids are nominated. This means that later, some part of it can be selected and activated and not so for non-nominated bids. The next step is bid selection, performed by an automatic algorithm in the LFC. This selects the minimal subset of bids amongst the nominated bids, but in merit order, that suffice to reach the required response. Next, bid activation is done in parallel and pro rata of the bid quantities. Also, bids are regulated to zero (respecting the regulated speed mentioned in the bid) if they do not occur in next ISPs. Energy demand is constantly monitored and recorded by the national LFC and FRR BSPs are also expected to record that information for their bids. Note that in Figure 6, all signals are real ones, since they do not affect real operations of the energy system. Activation of bids should also be seen as read, excluding the last part of it which would have an effect on energy systems. This is a non-exhaustive list of items that will be comforted by the dry-run trial: 1. General requirements: every signal should be sent and received and contents should be interpreted in the same way. 2. Scenario’s where the imbalance pertains for some steps should be simulated. 3. Scenario’s where mFFR can successfully replace aFRR bids should be simulated. 4. Scenario’s where bids do not occur in all periods and where these bids will have to be regulated to zero have to be simulated. 5. Is aFRR energy demand recorded both at the LFC and BSP side and do the data correspond when comparing them for the same bids. 4.2.5 Invoicing and Settlement for BSP (ABM Rules Chapter 11) We show the sequence diagram of Invoicing and Settlement between market operator and BSP in Figure 7. 19 Figure 7 Invoicing and Settlement Sequence Diagram Time goes from top to bottom in this figure, from the date (<