Questions_&_Answers.pdf

Questions & Answers

NIST-RFQ-19-02499

1. Mapping to the Energy Mashup Lab Architecture

The Energy Mashup Lab (The Lab) is a tax-exempt (501(c)(3)) non-profit whose purpose is to promulgate open source software platforms for smart energy and encourage the incorporation of transactive energy agents into buildings, systems, and devices (http://www.theenergymashuplab.org/). The Lab provides public repositories for its software and projects, some of which were used in the NIST-supported Transactive Energy Challenge. The Lab is an affiliated member of the Linux Foundation.

We plan to host all incremental and final work in The Lab’s public repositories. The Lab publicly defines its architecture for Transactive Energy 2015. See Enabling Energy Mashups (https://www.theenergymashuplab.org/blog/2015/8/7/enabling-energy-mashups) from which is drawn the simplified figure below)

The Transactive Shell in the figure buys and sells using the Common Transactive Services; the Actor is the active entity or device such as a microgrid, building system, building, or generator. The Agent Shell, which wraps the Actor, accepts requests for Energy from the Actor, and formulates them as directives to the Transactive Shell. If an Actor is able to change how much or when it uses power, for example, waiting for a particular price, the Agent Shell provides guidance to the Actor.

We see the Supervisory Controller described in the SOW as the Agent Shell. The Local Controller as the Actor. The TE Agent and Market Agent and Market Agent are different faces of the Transactive Shell. This mapping is based on the diagram in Figure 5 of the

SOW.

http://www.theenergymashuplab.org/ https://www.theenergymashuplab.org/blog/2015/8/7/enabling-energy-mashups https://www.theenergymashuplab.org/blog/2015/8/7/enabling-energy-mashups

TC9 Questions on SOW for TEMix Bilateral Market Software Development

The EML architecture provides higher abstraction which permits microgrids to act as Actors inside containing microgrids, and potentially multiple Actors within a single Agent Shell.

Is it acceptable for us to move forward under the assumption that within this Statement of Work the Local Controller is the Actor, the Supervisory Controller is the Agent Shell, and that the Market and TE Agents is the Transactive Shell?

If not, what would you suggest as a starting point for discussion?

Yes, it is acceptable to consider the Local Controller is the actor, the Supervisory Controller is the Agent Shell, and that the Market and TE Agents is the Transactive Shell.

2. The NIST Design The phrase “the NIST design” appears to be used loosely.

• In Section 3.1, “the NIST design” is first described in the future tense.

• At the end of the second paragraph of 3.1 “the NIST design” is used in the present tense.

Is it a goal of the project the project to create or refine “the NIST design”?

Yes. The NIST design, which is TE Agent + Market Agent implementing a bilateral market using EI TeMix services, conceptually exists but has not been implemented. This requirement is for contractor support services to implement the design.

3. Use of EIQuote We note that the EI TEMIX profile does not include EiQuote. The use of EIQuote appears throughout the SOW.

For purposes of this project, may we presume that the Common Transactive Services interactions (which include EIQuote) are meant where TEMIX Profile interactions are stated?

Per http://docs.oasis-open.org/energyinterop/ei/v1.0/os/energyinterop-v1.0-os.html, Table 14-2, EiQuote is included in the TEMIX profile.

4. Users and Operators

The Energy Mashup Lab (The Lab) is a tax-exempt (501(c)(3)) non-profit whose purpose is to promulgate open source software platforms for smart energy and encourage the incorporation of transactive energy agents into buildings, systems, and devices (http://www.theenergymashuplab.org/). The Lab is an affiliated member of the Linux Foundation.

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

The Lab describes the architecture of the future energy grid using a fractal model, i.e., a grid of grids. TE and Market agents appear within and at the boundaries of each fractal.

Working from The Lab’s architecture as a reference point, it seems odd to have an “operator MA” and an ”user TEA.” We suggest that eliminating the words Operator and User from Tasks 3 and 4 would align with current TE understanding and practice. Is this acceptable?

No, for the purposes of this requirement, please use the naming convention identified in the Statement of Work. This naming convention is for NIST purposes and is not intended to define who controls the Agent.

5. Definition of Baseline The term “baseline” is used in multiple ways that reduce clarity. The four items below are some of the points of confusion. Please explain; is it acceptable to simplify the terminology of the SOW in the project definition, deliverables, and documentation?

(1) SOW 4.1 p8 “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)”

The definition of baseline is as follows: “the expected hourly consumption for each customer for the simulated time window (e.g., one year)”

(2) SOW 4.1 p10 “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 what sense is this market position?

In simulation, there will be some market position calculated. During the first day, there are no market transactions based on DA market from previous day. During the first 5 minutes there is no transaction based on a previous RT price. The market position is therefore only the baseline during this initial 5 min of simulation time.

Is the MA (or auxiliaries) intended to populate a position from the “customer baseline data” which seems to be real usage, not projected or subscribed.

Yes, the MA (or auxiliaries) is intended to populate a position from the “customer baseline date.”

Does the subscription (committed consumption) get populated separately or from historical data? Please clarify

Subscription will be populated by data provided by NIST.

(3) SOW 4.2 p11 “Baseline Price… is treated as constant for all hours” and “Baseline Usage…for each hour of the day”. What is the source of these? It’s not clear whether this is historical, live, simulated, or other data. Is it adequate to turn file data into tenders?

NIST will supply the data required. File data shall be turned into a market position as if it were transacted upon.

(4) SOW 4.3 p13 (We have asked elsewhere whether this is indicative and example information) “For our implementation, the baseline is the initial indication of expected power flow.”

To clarify the quoted sentence: the customer has the pre-contracted baseline amount of energy per hour. This can be summed over the customer base to indicate the total power at the substation for each time interval.

Please explain this use of baseline.

Please see responses to each portion of the inquiry above, in-line.

Indicative Content vs Project Requirements

6. Meter and Party IDs Page 9 seems to conflate meter IDs and party IDs, so we assume that that implication is indicative, in other words, is an extended example of intended use, not a critical requirement for the project.

In addition, all of Page 9 appears to be indicative as noted in other questions.

Is this an acceptable interpretation?

Yes, this is an acceptable interpretation.

7. Use of Historical Data In Figure 5 Circle 1 on the left side appears to indicate the capability of either (a) taking historical data and turn it into simulated tenders or (b) taking live data and turn it into simulated tenders.

Is this an acceptable interpretation for NIST’s intended use of historical data files?

Yes. The initial simulations will use historical data. Future use shall assume connection to live data feeds.

8. Section 4 appears Indicative All of section 4.1 including figure 4 appears to be indicative not requirements.

Is this an acceptable interpretation?

No, Section 4.1 describes NIST requirements.

Project Details

9. Deliverables

The end result of the project appears to be to produce open source implementations as follows:

Implement the Market Agent and Transactive Energy Agent Implement the CTS between the MA, and TEA Implement integration capabilities via Java APIs with the MA and TEA

Is that an accurate high-level description of the project?

Yes, this is an accurate high-level description of the project.

10. Services and APIs In Figure 5 as we read it, the scope of the project includes the center column blue arrows (using the CTS) and the Java APIs to the TEA and MA to enable integration with actor software.

Is this correct?

Yes, where the actor software includes both WM and SC, via the Java APIs.

11. Market Prices The complexities of Section 4.3 appear to relate to determination of cost, as an input to an offer or tender from an energy supplier or sink. Typical TE approaches would use (in the terminology of the SOW) the LMP as the final price including all delivery, losses, and other costs. Thus, a tender into a market managed by a MA would be an inclusive price. Is this description of the project scope acceptable?

Yes. The MA issues all-inclusive prices to TEAs.

12. Use of ISO Price Streams Is it acceptable to take the ISO price streams (live or recorded in files) and deliver to the MA as prices including all costs?

Stated differently, may we assume that the details of supplier cost are not included/addressed in the project, and that a unitary LMP from each supplier will be provided that the MA and market may rely on.

Yes. The prices coming from the WM will be single all-inclusive LMPs.

NOTE: This is consistent with the TE-enabling approach in Energy Ecologies, Cox and Considine, Grid-Interop 2012.

13. Meters as Actor Proxies The baseline data (see also Question 5) appears to be historical data and requested use traces, and it seems that the LCs are proxied by the baseline reader for simulation purposes.

Is the creation of an actor to read WM traces and provide quotes in scope? Can it be considered part of integration with the project deliverables?

No, the creation of an actor to read WM traces and provide quotes is not in scope of this requirement and may not be considered part of integration with the project deliverables. Based on 3.2.2 and Fig. 4, the WM passes tenders to the MA based on DA and RT data files. Per response to Question 5 above, baseline data is converted directly to an initial market position at the start of simulation.

14. Meters as Actor Proxies (2) Task 5 “Expected output“ is not clear. It appears that the SC is reading meters (live) or (in the project) meter usage traces. Is it sufficient to use historical data to produce tender streams for what appear to be forward needs based on historical data?

Based on a historical trace, the proxied actor would emit “in the next five minutes I’ll use 5 units of energy.” Other data sources would similarly emit as prospective what are actually historical traces for the NIST trace-based simulation. In other words, do you expect

Is it sufficient to use historical data to produce tender streams for what appear to be forward needs based on historical data? In this manner the input files could be converted to an EI conformant data stream out of the sample trace files that NIST will supply.

Is this acceptable?

NIST will provide data for use. The TEA passes tenders and quotes to the SCs.

For the DA tenders, the SC responds with a transaction request to buy more or less energy based on expected usage for each hour in the next day. For this expected usage, for testing purposes, NIST may use results from previous simulation runs for the actual simulated energy usage (perhaps with randomized differences). NIST is providing the transactions based on SC expected usage in response to DA tenders.

15. Code Testing Code testing seems to describe importing trace data into a test harness but raises additional issues. See also Question 5 for ambiguity around the term “baseline”.

• End of paragraph 1, SOW 4.5, page 14: As above, one might anticipate simple emitters/adapters that take either live data or file data and emit CTS requests;

good practice would separate input sources, so the results are the same. Would unit tests of the file reading actor(s) satisfy the final sentence (The methods in the API that use raw data…”)?

NIST has a Java actor and intends to use the Java API to interface with the code produced from this Statement of Work. For testing, NIST seeks confidence that the Java API is working and feature complete. The sentence highlighted in the question is intended to convey that NIST wants the Java API to be heavily tested, but the only data NIST will make available at project start will be the input files described throughout the Statement of Work. If the unit tests cover the Java API, they are sufficient to satisfy the final sentence.

• Paragraph 2 suggests that there is a pre-determined (by file input?) subscription data, rather than the conventional meaning of “baseline”. Please clarify whether the “baseline subscription data” is (a) subscription information for each time interval and the length of the time interval—note that subscriptions seem in the literature to not be five minutes but longer.

Yes, “baseline subscription data” is synonymous with the earlier defined hourly interval baseline subscription (“the expected hourly consumption for each customer for the simulated time window (e.g., one year)”).

• The use of baseline subscription is also described in SOW 4.3, which we have asked whether it is indicative. Adding complexity to the MA seems poor architectural practice, as user-defined code can process this overly specific information.

• Paragraph 2 suggests a data reduction process that would in typical simulations not be done by the simulated engines but by data restriction prior to simulation.

Processing a voluminous file to determine what is in the relevant time range (and what should be ignored) seems more a function of simulation configuration and management than functionality that should be in the MA.

Is this functionality requested by NIST?

Yes, the functionality identified in this question, and each of its bullets, is required by NIST. The method of its implementation is the responsibility of the contractor to propose.

16. Non-Power Charges and Tender Prices See Question 5 for unclear use of the term “baseline”. In addition, in SOW 4.5 Code Testing p14, 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.

We have requested clarification that complex calculation of distribution charges and other fees unnecessarily complicates the project and reduces applicability to common TE scenarios. We believe that these calculations are out of scope for the project. Is this acceptable?

No, this is not acceptable; the calculations are in scope for the requirement. It is integral to the function of the market to apply market rules to calculate the charges.

What actor produces these tenders? Noting that tenders need not clear, and need not result in transactions, please explain the phrase “the MA shall respond with transactions.”

The MA produces the tenders. The MA, when operating as market maker, can take or leave a tender. But it must maintain a market price and have power to serve loads.

Project Management and Deliverable

17. Repositories

The Energy Mashup Lab (The Lab) is a tax-exempt (501(c)(3)) non-profit whose purpose is to promulgate open source software platforms for smart energy and encourage the incorporation of transactive energy agents into buildings, systems, and devices (http://www.theenergymashuplab.org/). The Lab is an affiliated member of the Linux Foundation. The Lab provides public repositories on GitHub for its software and projects, some of which were used in the NIST-supported Transactive Energy Challenge.

We plan for all work to be immediately available and publicly visible in the GitHub of The Lab. Working in another GitHub may risk significant administrative overhead and possible disconnects.

It is acceptable for the Contractor to work from its own GitHub repository.

However, that repository shall be forked from a NIST repository that will be created for this requirement.

What are acceptable schedules and procedures to align “a NIST GitHub” referenced SOW page 15 with the public GitHub of The Lab? We suggest weekly, or at each milestone in the project plan.

It is acceptable to create one pull request into the NIST GitHub repository for each major milestone. One branch will be used exclusively for this Statement of Work, and there should be minimal merge conflicts due to these pull requests.

18. Project Reviews The proposed review process does not align well with industry agile development, which typically requires shorter feedback cycles and more frequent builds.

To ensure usable outputs within the period of performance, an agile development approach with frequent microbuilds and rapid feedback is anticipated.

This would limit extensive up-front process, as one need not preload the meetings as much. Agile approaches generally start faster (given our knowledge of the issues, TE, and the EI paradigms there isn’t much of a learning curve) and flesh out the development structure during early meetings. The key goal would be to deliver the bulk of functionality early through the fall semester, and to provide usable code as early as feasible.

For agile and rapid development rapid feedback is essential.

Would it be possible for more immediate feedback on microbuilds (on the order of 2 days, not two weeks as in SOW p16 Section 6)?

Yes, more immediate feedback on microbuilds will be available.

19. Alignment of Project to Academic Calendar It benefits the project to engage university researchers and grad students during the period of performance. It appears that a timeline better aligned with school semesters would be beneficial to that engagement, e.g. starting July and ending December (six months).

What is the flexibility with regard to final deliverables, taking into consideration the usable intermediate deliverables?

The period of performance for this requirement has been updated from 120 days from date of award to 130 days from date of award, but is otherwise firm.

Deliverable dates may be updated by mutual agreement within the period of performance as the Project Work Plan is updated.

20. Limit Project Detail Tracking The solicitation is for a lean contract with maximum functionality in minimal time.

The overhead of managing and time tracking must be minimized or eliminated

We presume that with firm fixed price that we need exert no effort for detailed accounting of hours spent and by whom, only that the principals are engaged and managing, and regular deliverables.

We further anticipate industry common practice for agile development of pro rata billing at each month and a retention for final acceptance. This is more consistent with frequent delivery and short turnaround that we recommend.

Is this an acceptable interpretation with the RFP?

Yes, since this is a firm fixed price requirement, a detailed accounting of hours spent and by whom is not required for invoicing purposes. Instead, a firm fixed price payment schedule shall be proposed based on requirement deliverables.

21. Limit Project Detail Tracking

Is it allowed to utilize services from offshore (for example, from India) to perform part of this Java code development under supervision from BeyondSOA senior tech team while giving delivery assurance from our VA office? We mean primary contact and communication will be from our office in the U.S.

Contractors may utilize subcontractors in accordance with FAR 52.219-14:

Limitations on Subcontracting.