TeMix_Statement_of_Work_Revised_Amendment_02.pdf

NB732020-19-02499

Statement of Work for TeMix Bilateral Market Software Development

Acronyms and Definitions CPS cyber-physical systems DA day-ahead hourly market EI Energy Interoperation (OASIS standard) LC Local Controller LMP Locational Marginal Pricing MA the Market Agent representing the market operator Party any market participant Quote a non-binding price for some product during some time interval RT real-time 5 min market SC Supervisory Controller SPF distribution substation power flow, with positive flow direction toward distribution feeder TE transactive energy TEA the TE Agent representing a Party to interact with the MA Tender a binding offer for some market product during some time interval Transaction an agreement to transact some amount of energy product at some price for some time interval UCEF Universal CPS Environment for Federation WM Wholesale Market federate

1. Background

1.1 TE Modeling and UCEF

NIST has recently completed the Transactive Energy (TE) Modeling and Simulation Challenge (https://doi.org/10.6028/NIST.SP.1900-603) (TE Challenge) which had the primary goal to strengthen models and tools for TE co-simulation. This was done through the development of a TE abstract component model, and through a collaborative simulation exercise aimed at achieving comparable co-simulation results for a given common scenario. The common scenario was developed by participating TE Challenge teams and consisted of agreed upon: electric feeder populated with houses and attached loads and generation, weather and electricity prices for a day, and metrics for evaluation.

The co-simulation scenario specifically looked at the ability of each team’s different TE model to manage voltage deviations on the distribution feeder.

The TE abstract component model was developed by participating organizations (https://doi.org/10.6028/NIST.SP. 1900-750) and is presented in more detail below. NIST is assembling software and/or hardware implementations that realize the interfaces of this model using its Universal CPS Environment for Federation (UCEF, https://pages.nist.gov/ucef). UCEF is a development environment and software library for federated experiments with cyber-physical https://doi.org/10.6028/NIST.SP.1900-603 https://doi.org/10.6028/NIST.SP.%201900-750 https://pages.nist.gov/ucef systems (CPS). This tool suite integrates leading simulation engines and hardware-in-the-loop within a distributed modeling and simulation architecture, to facilitate communication and information exchange between the various simulators, emulators, and hardware from multiple researchers and companies.

The contractor shall develop part of a market component to be used in TE simulation experiments.

1.2 TeMix

OASIS TeMix is the set of transactive services in the OASIS Energy Interoperation (EI) standard1. It is a profile of EI, as given in EI Section 14.2, that includes the following EI services: EiRegisterParty, EiQuote, EiTender, EiTransaction, EiEnroll, EiMarketContext, and EiDelivery.

The services that matter in EI TeMix for market operation are EiQuote, EiTender and EiTransaction. The other services relate to establishing participation (Register, Enroll and Market Context) and settlement (Delivery). Use of EI TeMix is fundamentally about operating a market using these services. This is described in the Common Transactive Services paper2 developed as part of the NIST TE Challenge Phase I effort3. The EI TeMix services may be used to implement different market designs, whether a double auction with clearing price, a bilateral market4 or something else.

2. Scope of Work The purpose of this acquisition is to procure contractor services to develop a Java software product that simulates the TeMix energy marketplace designed by NIST. Specific Tasks may be found in Section 5 of this Statement of Work.

The work requires development of the two independent software modules that enable operation of a TeMix bilateral market within a TE simulation experiment operating in the UCEF environment. These two modules are the market operator’s Market Agent (MA) and the individual market participant’s TE Agent (TEA). The MA operates the market while the TEA represents the customer to buy and sell some energy product in the market in order to meet customer energy needs or provide some energy product to the market, thereby providing some energy service to the grid. These two modules shall be released as a software library that can be easily invoked from Java code. The application programming interface (API) for this library shall be designed to support its eventual use in a UCEF co-simulation environment. This scope of work does not

1 OASIS Energy Interoperation standard 1.0, 2014, at: http://docs.oasis-open.org/energyinterop/ei/v1.0/os/energyinterop-v1.0-os.html.

2 Cox, W., et. al. (2016) Common Transactive Services. https://s3.amazonaws.com/nist-sgcps/TEChallenge/Library/CTS-Report-20160502.pdf.

3 Holmberg, D., Bushby, S., TE Challenge Phase I Report, NIST Tech Note 2019, 2018.

https://doi.org/10.6028/NIST.TN.2019.

4 TeMix services have been implemented in an SCE bilateral market pilot, “Retail Automated Transactive Energy System”, 2016-2018, at: https://rates.energy/.

http://docs.oasis-open.org/energyinterop/ei/v1.0/os/energyinterop-v1.0-os.html http://docs.oasis-open.org/energyinterop/ei/v1.0/os/energyinterop-v1.0-os.html https://s3.amazonaws.com/nist-sgcps/TEChallenge/Library/CTS-Report-20160502.pdf http://docs.oasis-open.org/energyinterop/ei/v1.0/os/energyinterop-v1.0-os.html http://docs.oasis-open.org/energyinterop/ei/v1.0/os/energyinterop-v1.0-os.html https://s3.amazonaws.com/nist-sgcps/TEChallenge/Library/CTS-Report-20160502.pdf https://s3.amazonaws.com/nist-sgcps/TEChallenge/Library/CTS-Report-20160502.pdf https://doi.org/10.6028/NIST.TN.2019 https://rates.energy/ include development of the UCEF federate and limits itself to the development of this Market Agent and TE Agent library that could be used by a UCEF federate.

3. TeMix Market Design and Interfaces

3.1 NIST TeMix Bilateral Market Concept and Design

The NIST design will implement a bilateral market using EI TeMix services. The market operator receives tenders to buy or sell energy and then distributes these tenders to other market participants. These tenders offer to buy or sell some energy product for some price for some time interval, potentially scoped by a limited locational area. There is no submission of bids with subsequent market clearing price. There is no discrete day-ahead or real-time market, and any party in the market can buy or sell from another party. Tenders can also be accepted in part; many parties (e.g., residential customers) could transact (purchase) energy made available in a single tender by the local utility as a party to the market.

Each party’s transactions are additive for each time interval ahead of delivery and together form a market position. For example, a customer may purchase an amount of power for each hour of the following year (or this amount is assigned by the distribution utility based on prior-year consumption levels), then make a transaction to adjust market position on the day ahead based on the weather— that is, by buying more or selling back some of the already-reserved energy. This might happen again closer to real time based on better knowledge of actual upcoming usage or a changed real time price that incentivizes more or less consumption. In the final “now” interval, the customer uses some amount of power that is likely different from the previously committed market position, and this difference is made up with an ex-post transaction at some real-time market price, per some pre-agreed market rules. The NIST bilateral market design implements these concepts.

The NIST design does not specify registration of participants. For simulation purposes, each participant is assumed to be a registered party with a Party ID.

The market allows any market participant (“party”), represented by its TE Agent (TEA), to submit tenders to an operator’s Market Agent (MA) which forwards tenders to other parties. The MA tracks the market position of each party and uses validated meter data to settle accounts, issuing balancing transactions to account for under or over use of energy during each interval. This is made possible with access to customer meter data. The MA must also keep a record of all currently standing transactions that make up a party’s market position (future intervals), plus store some record of transactions for past intervals in order to perform settlement.

Each party is represented in the market by a TEA. The TEA is responsible to represent market tenders to the customer and customer’s intelligent systems, and to represent the energy product purchase and sales plans to the energy market in order to acquire or sell energy.

Figure 1. Market operation. Each participant is represented by a user TE

Agent (TEA). The operator’s Market Agent (MA) operates the retail market and interacts with wholesale market(s). Communications between TEA and

MA conform to Energy Interoperation transactive services.

The wholesale market in Fig. 1 represents the bulk electricity market which typically sets the price in the local retail market (represented by the Operator Market Agent and TEAs) when bulk power supply is not constrained. The local market might represent a feeder attached to a substation on the bulk grid, and receives pricing at the substation that is called “Locational Marginal Pricing” (LMP). A wholesale market operator such as CAISO or PJM runs both a day-ahead (DA) market and a real-time (RT) market. The PJM DA next day hourly prices are released at 1:30 pm day ahead and valid for rebid for 45 min5. The retail market agent distributes the DA prices as tenders to the customer TEAs.

The PJM RT market provides prices for energy delivered to the LMP substation node every 5 minutes, and these prices are distributed 2 min prior to the interval6. This market timing will be used in simulation.

In the case of a constrained bulk market, or the limiting case of an islanded microgrid, the retail energy market prices may not be determined by the bulk market energy prices. Rather, the MA may need to operate as a market maker, buying energy from available sources and selling to available buyers. In this case, a TEA will not only be transacting on tenders from the MA but will be generating tenders to either buy or sell. For example, if there is an unexpected load coming in the next hour, a TEA may issue a tender to buy power for the next hour. On the other hand, depending on prices and weather, a TEA might issue a tender to sell some power back to the system. For its part, the MA may need to maintain a market price for each hour of the current and next day as well as next 5 min RT price.

5 see here, here for PJM example.

6 The timing given here is based on observations of released data from the page here.

https://learn.pjm.com/three-priorities/buying-and-selling-energy/energy-markets.aspx https://www.pjm.com/-/media/training/nerc-certifications/markets-exam-materials/mkt-optimization-wkshp/two-settlement.ashx?la=en https://pjm.com/pub/account/lmpgen/lmppost.html

3.2 Components and Interfaces in Co-simulation

The simulation components used for the NIST co-simulation experiment and the interfaces between the components are based on the TE Abstract Component Model (TE Model) developed as part of the NIST TE Challenge. The TE Model has the following components: Grid, Resource (load and generator), Local Controller (LC), Supervisory Controller (SC), Transactive Agent, and Weather, as seen in Fig. 2 (taken from above referenced TE Model paper). Figure 2 provides context for how different components may represent actual DER, markets, plus the grid.

Figure 2 Notional topology illustrating TE Model building blocks

These components, for the purposes of this project, might be viewed as shown in Fig. 3.

Figure 3 Components (blue boxes), interfaces (double headed arrows), and inputs/outputs (white boxes). The Transactive Agent of Fig. 2 is decomposed into Market Agent (MA) and TE Agent (TEA).

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1900-750.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1900-750.pdf

3.2.1 Function of Components

The Market Federate (Fig. 3) contains the operator’s MA and the user’s TEA.

The MA operates a retail market and interfaces to wholesale markets. The MA manages the retail market according to the market design and passes tenders to the TEA. The MA associates each TEA with a specific meter (there could be multiple TEAs for a single meter). The MA tracks energy use/production market positions for each meter account based on buy and sell transactions. The MA tracks validated meter reads for each account (from utility metering/billing service provider) and settles accounts ex-post.

The TEA receives tenders from the MA sent to its own MeterID (see EiTender message schema per Energy Interoperation specification7) and then passes the tender information to its attached SC. The TEA receives back a response to issue a transaction based on each tender (e.g., purchasing energy). The TEA then issues the transaction to the MA (via EiTransaction message). If forecast generation or load changes after completing a transaction, then additional transactions may be issued to correct for changed conditions, as long as the tender is valid. Alternatively, load may be adjusted and battery charging or discharging may be changed to compensate for changed forecasts. Note that it is the SC that is doing the forecasting, making decisions on how much to transact and sending control signals to LCs. The TEA follows with transactions to the MA.

The MA responds with EiCreatedTransaction messages to confirm each transaction is then passed on to the SC.

The SC knows (regularly queries to know, or queries after the receipt of a tender) the energy needs of attached LCs for future time intervals. It knows the flexibility of attached LCs, which it may find via different methods as appropriate. The SC responds to each tender to indicate amount of energy to transact whether zero or non-zero. The SC maintains a log of all current transactions so that it knows its market position (based on committed transactions) at all times, and then manages energy consumption accordingly. For example, there may be a committed transaction for the coming hour for 10 kWh at 0.05 $/kWh. The real-time price might be at 0.20 $/kWh for the same interval and the customer will either have to pay 0.20 $/kWh for additional energy or will be paid 0.20 $/kWh (ignoring transaction fees) for any reductions below 10 kWh.

The SC may also calculate price levels. Price levels communicate to attached LCs the meaning of a tendered price, whether a “normal”, “high”, “critically high”, or “low” price. Such a classification aids the LC in deciding control actions. The price level itself is calculated based on some algorithm that looks at past prices to see how the current tendered price compares to previous prices. The algorithm may consider day of week or season or other components in addition to archived prices. The SC must archive past tendered prices and may group these according to the type of tender (e.g., DA hourly tenders vs. RT tenders).

7 http://docs.oasis-open.org/energyinterop/ei/v1.0/os/energyinterop-v1.0-os.html

The SC issues price levels based on received tendered prices and/or estimates of future prices and the price levels may be used by attached LCs to estimate forward energy requirements in order to respond to SC requests for same.

The SC passes prices and/or price levels to LCs via some building or home management protocol and receives back calculated energy requirements (based on resource models) for upcoming time intervals, whether as a load curve or some other format. These energy requirements from the LCs are aggregated and used by the SC to formulate transactions and tenders to be sent to the TEA.

In simulation, an SC tracks actual consumption based on its knowledge of the consumption calculated by the LCs. In real life, meter data would come from the meter at the house and/or a meter data provider. In simulation, the Grid component relies on resources to calculate power consumption, whereas in the real world a grid operator would use estimated consumption based on market transactions and/or forecasts.

The Local Controller is responsible for controlling a specific resource (load/generator). It may read various parameters as needed to understand resource status, and then control a device. It may also access a weather feed as needed, for example, to estimate forward cooling requirements for a home, or energy production for a PV system.

The final component in the model is the Grid itself: wires and equipment in addition to loads and generators attached to the distribution system. In the real world, a distribution system operator (as grid operator) might also operate the market, but in any case needs to know market commitments in addition to system status (voltages and power flows). To simulate this, the Grid component must receive either transacted power for the next time step from the MA, or (as it is set up in GridLAB-D) receive from the SC/LC the estimated power consumption in the next time interval.

3.2.2 Interface Information elements

Reference interfaces are shown as double-headed orange arrows in Fig. 3. The information elements passed between Model components are summarized here.

WM↔MA

• Tenders from WM to MA

• Transaction record from MA to WM

MA↔TEA (via Energy Interop)

• Quotes: Market ID, Party ID, time interval, product, buy or sell

• Tenders: Party ID, Tender ID (to be assigned by MA), time interval for production or consumption of energy product, product, amount available, valid time interval for transaction, buy or sell, market context, optional:

location, optional: modifies Tender ID

• Transactions: Tender ID, amount

MA↔Grid

• 5 min interval meter data from Grid to MA for each customer account.

TEA↔SC

• TEASC

o Quotes o Tenders o Confirmation of transaction

• SCTEA

o Request to issue tender o Request to issue transaction

SC↔Grid (not part of this contract)

• (in simulation) SC sends to Grid aggregated (at house meter) power draws, real and reactive for next time step. Alternatively, each LC may send this data to Grid.

• Grid sends voltage back to SC. In real world, if SC/LC needs voltage, it measures it locally.

SC↔LC (not part of this contract)

• SC sends prices and price levels for forward time intervals. SC might do this as a “next day hourly prices” array based on available tenders, plus “next 5 min price” based on real-time quotes.

• SC may send artificial prices (higher or lower) to probe flexibility, or use other means to estimate or ascertain flexibility to prepare for possible tenders, or to communicate flexibility to market (considering a double auction market format where a bid curve would be required)

• LC returns load/generation curve for forward intervals LC↔Resource (not part of this contract)

• LC controls the resource, reading sensors as needed.

4. General Requirements This section provides general requirements that the contractor shall follow in performing the Specific Tasks identified in Section 5 of this Statement of Work.

4.1 Simulation Flow

The simulation flow for key interactions for planned TE simulations are shown in Fig. 4. At the start of the experiment, the MA shall read customer baseline data from file (to be provided by NIST; see format in 4.2). This baseline is the expected hourly consumption for each customer for the simulated time window (e.g., one year). After the simulation starts, the MA shall begin to receive tenders for next day market intervals plus real time quotes for the next 5 min interval.

These will be received from the Wholesale Market (WM) federate. The WM releases (at 1:30 pm) 24 tenders for the 24 hourly intervals of the next day. The WM releases 5 min tenders at 2 min before each 5 min interval.

Figure 4 Simulation progression of messages for market operation.

Figure 4 shows the processing of information by MA and TEA in order to issue tenders, execute and then record transactions. At the top of Fig. 4, in the track with the blue circle “1” label, the MA receives DA tenders from the wholesale market, calculates loss, delivery and fees and then passes 24 DA tenders to the TEA. The tenders shall be valid for 45 minutes. The TEA passes the information from the tenders to the SC federate which will interact with LCs to get load estimates for the next day based on those prices and then issue (back to TEA) requests for transactions for each tender. The TEA shall then issue transaction requests to MA and receive back confirmations that are then passed to SCs.

Since transactions are made for the next day, the first day of simulation shall have no market commitments based on DA tenders. The market position shall be based only on the baseline, and then balancing transactions will be made based on RT prices. The balancing transaction for the first 5 min of the first day shall be set to zero.

In track “2”, the MA receives the RT tenders from the wholesale market (input data file) every 5 min and then issues an RT quote to market participants (TEAs) at 2 minutes prior to the upcoming 5 min interval. The TEA receives the RT quote and passes information on to the SC federate. The SC will pass prices and/or price level signals to LCs with no response back and no transaction. In simulation, LCs calculate expected power usage and send this value to the Grid component to be used in the next time step grid solution. The wholesale market tender’s transaction window will extend 5 minutes past the end of the applicable RT interval, allowing the MA to calculate ex-post balancing transactions based on meter data in order to settle customer accounts. All transactions (DA plus balancing) shall be written to file as the simulation progresses.

In track “3”, the LC reevaluates energy needs or surplus based on weather and price changes and indicates this to the SC. The TEA shall allow the SC to issue a request to the TEA for a tender to buy or sell energy. The TEA shall form a tender and send to the MA (without a price or distribution charges). The MA shall complete the needed tender information, adding the market price (as market maker it maintains the market price) and the distribution charges. At this point the MA shall complete a transaction on that tender to either buy or sell the energy.

This transaction record shall be passed on to the SC to confirm and to enable the SC to track market position.

The TEA shall be released as a separate piece of Java code from the MA code.

Each part implements the Energy Interoperation (EI) TE services as the interface between them. In addition, the contractor shall supply an “EI Listener” that captures each EI message between MA and TEA and writes these to file. This will be used for testing purposes only, with details to be discussed at the Start of Work meeting (see Specific Tasks section). The messages that cross the red border labeled market federate, between the MA and the WM federate as well as between the TEA and the SC federate, shall be part of the library API. The API shall be able to handle the two cases where these messages are files stored on disk, and raw data passed to a method using some data structure.

4.2 Message formats

• Baseline data: hourly usage for each customer as an input file with:

o header that includes:

MeterID (customer meter, type=string) Baseline Price (for each hour, type=float, unit=USD). Note:

baseline price is treated as constant for all hours.

o and for each meter:

Date (of the meter reading, type=datetime) Baseline Usage (type=float, unit=kWh) for each hour of day o Data will be provided by NIST in XML format.

• Tender format: this is the tender information that shall either be read from a file or provided as raw data to a method to represent tenders from WM to the MA and from SC to TEA. This is also the data that shall either be written to a file or returned as raw data by a method to represent information transfers from TEA to SC. The elements shall include:

o Market Context (details on the market, type=URI, empty in our case) o Party ID (for the bulk market or TEA, type=unsigned integer) o TenderID (assigned by WM or MA, type=unsigned integer) o Buy or Sell (indicating buy or sell tender; type=string, value = “sell” in case of WM offering energy to the retail market) o Product (energy product being sold, type=string, value = “energy”) o Product unit (unit of product, type=string, value = “kWh”) o Start time (start of interval, type=datetime) o Duration of interval (length of interval in seconds, type= unsigned int) o Expiration time (time that tender expires, type=datetime) o Tendered amount (max product amount available with this tender, type= float) o Tender unit (type=string, value=“$/kWh”) o Tendered price (price for each unit of product, type=float. This can be the WM Total LMP or the MA-calculated LMP+distribution charges) o Distribution charges (if available, will be inserted by MA if tender originates from WM or from SC via TEA) Delivery (type=float) Loss (type = float) Fixed (type = float) Transaction (type = float)

• Transaction format: Transaction sent from SC to TEA (either by file or raw data) in response to each tender. Elements include:

o Tender ID (type=unsigned integer) o Amount (how much to transact, positive into house, negative out, type=float)

• Transaction Record format: Takes the information from the EiCreatedTransaction and sends to WM and to SC, written to file or returned as raw data:

o TransactionID (assigned by MA, unit=unsigned integer) o TenderID (to which this transaction responds) o Amount transacted (type=float) o Energy price (type = float) o Delivery, Loss, Fixed, and Transaction charges (type = float)

• Quote format: Quote for RT prices sent from TEA to SC, written to file or returned as raw data. Elements include:

o Party ID (for the bulk market, type=unsigned integer) o Quote ID (assigned by MA, type=unsigned integer) o Buy or Sell (type=string, value = “sell” in our case) o Product (what is sold, type=string, value = “energy” in our case) o Product unit (unit of product, type=string, value = “kWh” in our case) o Start time (start of interval, type=datetime) o Duration of interval (length of interval in seconds, type= unsigned int) o Expiration time (time that quote expires, type=datetime) o Quote unit (type=string, value=“$/kWh”) o Quote price (price per unit of product, type =float)

• Meter data format: the MA receives the total kWh consumption at each meter after the completion of each 5 min interval. Elements include:

o Time (start of interval for consumption, type=datetime) o MeterID (customer meter, type=string) for each meter o Consumption (type=float, unit=kWh) for each meter

4.3 Calculating Delivery, Loss and Fees

Distribution charges for delivery, loss and fees are specified as follows:

• The parameters listed here (Adeliv in $/kWh, Bdeliv in $/kWh/kW, Cdeliv in $/kWh/kW2, Closs in $/kWh/kW2, Cfee in $/kWh, and Ctransaction in $/transaction) shall be configurable up front in the code. The equations themselves shall be clearly demarcated in the code to allow reworking.

• Distribution charges are calculated at the time of tender issue (at MA) and circulated with the tenders.

• Delivery charge per unit of customer consumption ($/kWh) shall be a quadratic function of the substation power flow (SPF, unit=kW):

o Delivery-charge = sgn(SPF) * (Adeliv + Bdeliv * |SPF| + Cdeliv *

(SPF)^2).

o The charge will be negative if the power flow is toward the bulk grid.

• Loss charge per unit of customer consumption ($/kWh) shall be equal to some constant (Closs) times the square of the power flow at the substation.

o Loss-charge = sgn(SPF) * (Closs * (SPF)^2).

o The loss charge will be negative if the flow is toward the bulk grid.

• Additional fees shall be set initially as a constant of Cfee per unit of customer consumption ($/kWh). This fee can be used to cover costs for metering, billing, and other legally-required public purpose costs.

o Fixed-fee = Cfee

• Transaction fees ($/transaction) shall be charged to both buyer and seller with different sign depending on the direction of the customer power flow (CPF), whether positive (into the house) or negative (flowing out of the house). The cost is increased for the consumer, and payment decreased for the generator.

o Transaction-fee = sgn(CPF) * Ctransaction

• Total distribution charges ($) = (Delivery-charge + Loss-charge + Fixed-fee) * transacted amount + Transaction-fee

• Distribution tender/quote price (sell price from market to consumer, or buy price for sale from prosumer to the market) is:

o Energy-price ($/kWh) = Wholesale LMP (for DA tenders or RT quotes) + Delivery-charge + Loss-charge + Fixed-fee o In a constrained market with MA acting as market maker, the

“Wholesale LMP” in the above equation is replaced with the market price.

In a low load situation (and thus low LMP), with sun shining and backflow to bulk grid, the LMP is low, and both delivery and loss charges are negative. The result is that the local market distribution tender price for consumers may be negative.

In this case, loads will be strongly encouraged to consume more energy.

Likewise, the PV inverter with extra power would have to pay to flow that power on to the grid. This will incentivize battery storage to absorb the PV power when the sun is shining and move it to evening peak load period.

In a high load situation, LMP will be high, and the sun may or may not be shining, but the cost to purchase additional power from the grid will be higher due to the higher LMP plus the high delivery and loss charges. This incentivizes reduction of loads (shifting to lower price times) as well as discharge of batteries.

How is SPF calculated for a tender issued for some hour tomorrow? SPF may be calculated based on forecasts or on already committed transactions. For our implementation, the baseline is the initial indication of expected power flow. For DA-based tenders, the MA shall issue tender quantities equal to 25 % of the baseline subscription amount. If the customer transacts on the entire quantity, then the MA shall issue another tender of the same quantity (25 % of baseline), but with updated delivery and loss charges based on the better knowledge of already committed DA transactions. Likewise, RT price quotes shall include distribution charges based on all DA transactions for a given customer in the current time interval.

4.4 Output from code

In addition to returning the data specified above to the API user, the library shall create several files to log its internal operation. The following shall be written to file (as specified in Section 4.2 and shown in Fig. 3):

• Tenders from TEA to each SC

• Quotes from TEA to each SC

• Transaction records that follow each transaction finalized at the MA

(written to WM and those sent via TEA to SC)

In addition, the MA shall produce for each customer the record of transactions written to output files:

• Every DA hourly transaction with the following data: date, start time of interval, transaction ID, amount (kWh), and prices (Energy, Delivery, Loss, Fixed, Transaction, in $/kWh). All DA transactions for all customers for the entire simulation period shall be written to file.

• Every RT 5 min balancing transaction with the following data: date, start time of interval, balancing amount (kWh), RT price for this interval ($/kWh) and four Distribution charges. Each 5 minute period shall be listed, even if the balancing amount is 0 kWh. Customers shall be identified by Party ID.

Party ID will be the same as the Meter ID used by the Grid component.

• Totalized final 5 min kWh usage and cost for each customer with the following data: datetime of start of 5 min interval, total usage for this 5 min period, resulting total customer cost ($/kWh, all charges included).

4.5 Code testing

All input to the MA or TEA (not including EI communications between them) shall be specified in input files (provided by NIST with data as in 4.2), and all output from the code shall be stored in output files. The exact format of the files and whether the files are read once prior to running the experiment, or read at every simulation cycle will be discussed at the Start of Work meeting with the goal to produce MA and TEA software components that can (1) be later integrated into an HLA co-simulation environment and (2) be useful to industry as an open source code base for bilateral market agent development in real implementations. The methods in the API that use raw data instead of files shall be demonstrated to work using data from these input files.

MA inputs include the baseline subscription data for each customer for each hour of the experiment, plus all of the wholesale market DA and RT tender information. The MA also receives meter interval kWh consumption readings for each customer meter on the simulation cycle after the completion of each 5 min interval (all data as specified in 4.2).

MA outputs include the transaction records sent to the WM (see 4.2) and also the ongoing recording of all transactions and totalized consumption and cost (4.4).

The TEA passes all tenders to the SC as well as transaction records, both written to file. The TEA reads in transaction requests and tender requests from SC from files.

The testing approach and specific tests will be discussed at the start of work and more detailed plan provided in the project work plan deliverable (Specific Tasks Section 5, Task 2, section 4 deliverable). The basic plan is as follows:

• NIST will provide each required input file.

• NIST will use the API provided by the contractor for interactions with MA and TEA software components.

• Initial tests will use 30 TEAs and 30 baseline subscriptions. Final tests will use input file for 2000 customer meters.

• The experiment shall cover 2 days of input DA and RT price data.

• The SCs will respond (via provided API) to each DA tender with a requested transaction amount that will, for some meters, exceed the 25 % of baseline quantity of the first DA tender, requiring a second or perhaps third tender and transaction sequence.

• There will be some tender requests at odd times from some SCs to which the MA shall respond with transactions. The transaction shall use the market price equal to the previously tendered DA price for the requested (future) hour time interval. The distribution charges shall be calculated accurately for that future interval based on existing system baseline plus DA transactions for power flow at that interval.

• NIST will examine the output data files, including the EI messages recorded by the “EI Listener”.

• NIST will examine contractor code for efficiency (to minimize processing time) and documentation (clean and clear).

5. Specific Tasks The contractor shall complete the following tasks. All code shall be developed in Java. All code shall be regularly updated in a NIST Github repository and freely available to the public. All software shall be documented as it is developed, and the documentation shall be in that same public repository, on the same schedule as the code. All code shall be available under an Apache 2.0 license or equivalent as soon as it is made public in the repository.

Task 1 Meetings The contractor shall meet with the NIST Technical Point of Contact (TPOC) via web teleconference for a start-of-work meeting. The start of work meeting shall take place within one week of contract award During this meeting, the statement of work shall be reviewed and any questions answered.

The contractor shall also provide status updates on all contract tasks via web teleconference on a weekly basis after the start-of-work meeting.

Task 2 Project Work Plan

The contractor shall develop a project work plan that specifies in detail (more than is specified in the statement of work) the schedule, tasks and sub-tasks, and otherwise the plan for delivering requested software components that meet the NIST research goals. The contractor shall provide the draft project work plan to the TPOC for review within one (1) weeks after the start-of-work meeting. The contractor shall meet with the NIST TPOC via web teleconference to discuss the draft plan.

The contractor shall update the plan based on any TPOC feedback prior to TPOC approval. The final project work plan shall be submitted for TPOC approval within two (2) weeks after the start-of-work meeting.

The approved final project work plan shall be considered a living document and may be updated throughout the contract period of performance by mutual agreement of the TPOC and the contractor.

Task 3 Develop Operator Market Agent (MA) software module.

The Contractor shall develop the operator market agent software module according to requirements in Section 43. Draft software code shall be submitted for TPOC review and feedback within 90 days of contract award.

Task 4 Develop User TE Agent market participant The Contractor shall develop the user TE agent software module according to requirements in Section 43. The contractor shall also include an “EI Listener” for testing purposes that writes all EI messages between MA and TEA to file. Draft software code shall be submitted for TPOC review and feedback within 90 days of contract award.

Task 5 Testing and final delivery In parallel with Task 3 and Task 4 development, the code shall be tested against NIST-provided input data to generate expected output. The contractor shall justify why the generated output is as to be expected in order to demonstrate correct operation of the TEA and MA code modules. Within two weeks after TPOC feedback is received for Tasks 3 and 4, a second draft of software code for Tasks 3 and 4 shall be delivered with analysis of test results. The TPOC will review and provide any final feedback. Final documented code and test results shall be delivered within 10 days after final feedback is provided.

6. Timeline, Deliverables and Deliverable Due Dates The contractor shall provide the following draft and final deliverables to the TPOC in electronic format, unless otherwise agreed upon. The TPOC will provide written comments to the Contractor within 10 business days of receiving each draft deliverable. Final deliverables shall be provided by the Contractor within 10 business days after receiving comments from the TPOC. The project will have the following phases and deliverables according to this schedule.

Phase I – Task 1 and 2 initial meeting, review and agreement on technical details of implementation

Deliverable Due Date

• Start of Work meeting

• Requirements review and discussion.

• Discussions begin via email and telephone after award of contract.

Initial verbal discussions will take place at Start of Work meeting during first week of contract award.

• Draft Project Work Plan for Tasks 3 & 4 submitted by contractor.

• For review and discussion at web meeting one week from the initial web meeting.

• Final Project Work Plan submitted based on agreement in web meeting and further discussions.

• 2 weeks after start of work meeting

• Status Report web conferences

• weekly thereafter

Phase II -- Task 3 and 4 MA and TEA, including Task 5 Testing

• Draft MA and TEA code and draft output with analysis of output showing how the code results are as to be expected based on input.

• Within 90 100 days of award.

• Code and initial test results analysis will be reviewed in a web meeting.

• Second draft of code with analysis of test results.

• Within 2 weeks of draft review.

• Code and test results analysis will be reviewed in a web meeting.

• NIST will do final review after the meeting and provide requests for changes within one week.

• Final documented code, test results.

• 10 days after receiving any change requests from NIST.

7. Period of Performance

The period of performance shall be 120 130 days (4 months) from the date of award.

8. Place of Performance

The place of performance shall be the Contractor’s facility.

9. Government-furnished Property, Data, and/or Information

The Government will not furnish any property, materials, or equipment.

10. Risk Assessment

No risk level required. The contractor will not have access to a federal facility and will not have access to a Department of Commerce network.

11. Performance Requirement Summary

Desired Output

Required Service Performance Standard

Monitoring Method

Project Work Plan

To document the implementation plans for Task 3 and 4 deliverables

Clearly documented plan to deliver solution.

Verified by NIST TPOC and their delegates for completeness and technical accuracy.

MA and TEA code along with test results

Provide Task 3&4 software as Java code library that will be publicly available for use by other researchers interested in TE simulation and TE market implementations

Clearly documented code that meets technical specification. Test results with data output along with validation.

Verified by NIST technical contact and their delegates for completeness and technical accuracy.