TE Challenge Phase II Team Collaboration Meeting Overview

The TE Challenge Phase II team collaboration meeting on May 9, 2017, focused on introducing participants, discussing the Abstract Component Model, reviewing the Challenge Scenario Development Process, and setting goals for partnership and interoperability among tools. The meeting agenda included participant introductions, model feedback exercises, and steps to enable comparison of transactive methods across platforms. Teams were encouraged to utilize an abstract model, provide feedback for model enhancement, and implement interfaces for data exchange. The proposed Challenge Scenario Narrative centered on a feeder with high PV penetration experiencing reverse power flows and over-voltage conditions, demanding transactive methods for load/generation response.

• Team Collaboration
• Abstract Component Model
• Challenge Scenario Development
• Interoperability
• Transactive Methods

aad_cra Follow

Uploaded on Oct 04, 2024 | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

Presentation Transcript

1. TE Challenge Phase II Team Collaboration on Challenge Scenario Initial Meeting May 9, 2017

2. Meeting Agenda 1. Participant Introductions 2. Discuss use of the Abstract Component Model 3. Review and discuss the strawman Challenge Scenario Development Process 1. What is included 2. Narrative 3. Grid topology 4. Implementation steps for the Challenge Scenario 4. Next meeting(s) and homework N I S T s m a r t g r i d p r o g r a m

3. Introductions Name and organization and your plans for Phase II What tools and co-sim platform are you using? Are you looking for partners? What are your goals for that partnership? A note on goals for the process: We hope to advance interoperability among tools through common metrics, common interfaces, and shared understandings. We hope that through this process we connect co-simulation platform developers together with a larger user base. N I S T s m a r t g r i d p r o g r a m

4. Abstract Component Model for TE co-simulation The model on Github How teams can make use of it: Intellectual UML exercise map your platform model to the abstract model Provide feedback to strengthen the model Implement some interface that enables interoperable exchange of data, and which could enable an external tool to connect to your platform What do you think your team can do and what questions do you have? N I S T s m a r t g r i d p r o g r a m

5. Challenge Scenario Goal we want to enable comparison of transactive methods across different platforms by implementing a common event narrative on a common grid, with results reported with common metrics. What is the Challenge Scenario? The narrative (clouds passing over distribution feeder) The R1-12.47-1b grid (not mandatory to use this) Common metrics for reporting (minimum set that all use, plus additional potentially) Implementation steps: 1. Baseline event day, no weather, no market 2. Add weather and dynamic electricity price (homes are price-takers no TE bids) 3. Add your TE market N I S T s m a r t g r i d p r o g r a m

6. Proposed Challenge Scenario Narrative Electric feeder with high penetration of PV. At mid-day on sunny day, the feeder has reverse power flows and over-voltage conditions. At noon, a storm front overspreads the feeder and PV power production drops from full sun to 10% sun in a period of 10 min. This is followed by a ramp back up to full sun from 1:30 - 2:00 pm. Transactive methods are used to incentivize load, generation or storage response as needed throughout the day, and the transactive signals are localized to the feeder level to respond to voltage levels. Focus on distribution grid and challenge of DER integration (PV, batteries) Based on Scenario #3 in SGIP TE Application Landscape Scenario white paper Question: Can this scenario work for your team (you can study the impact of some TE method on the grid or customer resources)? Question: what changes would make this more useful for your team? N I S T s m a r t g r i d p r o g r a m

7. R1-12.47-1b grid Semi-rural radial feeder. Currently in Gridlab-d format. Published in the PNNL GitHub TESP directory as SGIP1b.glm Includes 1500+ homes (with variation in size, load) Some homes have PV, and some of those have batteries Also some unresponsive commercial loads And an elementary school modeled in EnergyPlus. Questions: How to make this useful for all teams (format issue)? Do we need the school? What control algorithms will we use for house loads and batteries? What if this grid topology is unworkable for your team? N I S T s m a r t g r i d p r o g r a m

8. Challenge Scenario Grid Topologies R1-12.47-1b feeder Semi-rural distribution feeder with 1540 homes 30% of homes have PV on roof and 33% of these homes have battery systems Some percentage of non- responsive loads on grid and in homes. Other grid topologies are possible to suit team requirements N I S T s m a r t g r i d p r o g r a m

9. Common metrics Start discussion of the metrics topic in meeting #2 N I S T s m a r t g r i d p r o g r a m

10. Implementation steps Steps 1. 2. 3. Rationale Step one allows us to get the basic indication that we have similar results (using common metrics) for the same grid. Step 2 lets us work out weather and price inputs, where we can check common PV response to clouds, house load response to temps, and control algorithm response to price. Step 3 then allows us to see how different TE methodologies perform relative to the common baseline scenario. Questions: does this approach make sense? Changes? Step 4 additional research according to your own research goals ideally using the same metrics and demonstrating interoperability, collaboration and lessons learned from the Challenge Scenario. Reporting results Results from implementing Challenge Scenario reported in common metrics Results form other scenario or variation that is investigated Any useful lessons learned in the process that can help advance the state of the art. Baseline event day, no weather, no market Add weather and dynamic electricity price (homes are price-takers no TE bids) Add your TE market N I S T s m a r t g r i d p r o g r a m

11. Homework for next meeting All teams provide written input: How will you implement the common platform model interfaces/components? How can the proposed Challenge Scenario be best used and improved to benefit Challenge goals, team collaboration and individual team goals? Narrative Grid topology Implementation steps Metrics TBD N I S T s m a r t g r i d p r o g r a m

12. Meeting schedule April 20, 2017 TE Simulation Challenge Phase II Launch. May 9 Challenge Scenario Development Meeting #1 Follow-on meeting schedule (approx. bi-weekly) see next slides June 14, 2017 Face to face meeting and Scenario Workshop at the GWAC TE Systems Conference in Portland, OR. January 2018 TE Challenge Capstone Meeting to share simulation results. Collaboration site: https://pages.nist.gov/TEChallenge gives access to the latest documents N I S T s m a r t g r i d p r o g r a m

13. Meeting #2 May 16 (Tues, 1:00-2:30pm ET) What time works best? At the meeting: Discussion of feedback from first meeting. How can we best use the Challenge Scenario? How can it better work for you? How will you use the Common Abstract Model? Team formation and goals for each team: use of common platform model, feedback on implementing the Challenge Scenario, team research goals. Common metrics: review status and discuss team needs to refine list. What are the next steps for scenario implementation? Homework: Each team prepare an implementation plan for the Challenge Scenario with goal to try to run baseline (null case) scenario and storm passing event scenario on grid by end of June, if possible. If you are not part of a team, then work with me and others to figure out teams. What part of the common platform model (components/interfaces) can you implement to enable interoperation with market, weather, resource or other model components? What metrics are important to your team, what standards for those metrics? Prepare a one page summary if possible that can be shared with a team introduction on our collaboration page. N I S T s m a r t g r i d p r o g r a m

14. Meeting #3 May 30 (Tues, 1:00-2:30pm ET) At the meeting: Review updated Challenge Scenario and team expectations. Discussion. Team formation review which teams we have and their plans for TE Challenge participation (based on homework response). Sharing/discussion on implementations how are groups doing, any questions or difficulties that you need help with? Discussion on the best use of the next meeting, perhaps for discussion of Scenario implementation efforts and problems, further revisions of the Scenario itself and presentation of those changes, team formation activities, etc. N I S T s m a r t g r i d p r o g r a m

15. June Meetings Meeting June 6 (Tues) TBD goals Review of plans for following week meetings at TE Systems Conference in Portland. Homework: prepare slides for presentation in Portland. Meeting at TE Systems Conference, June 13-15, Portland, OR TE Challenge Scenario Workshop, Wed, June 14, 5:30-7:00pm. Opportunity to connect face-to-face, present research objectives, build teams, plan for Scenario implementation work and beyond to accomplish team research goals. N I S T s m a r t g r i d p r o g r a m

16. Meetings after TE Systems Conference (Portland) Meetings June 28 (Wed, 1:00pm ET), July 5 (Wed, 1:00pm ET) and 11 (Tues, 1:00pm ET): Perhaps have additional participants joining. Discussion of any further updates to Challenge Scenario or implementation based on initial experiences of some teams. Presentations by teams on initial simulation efforts (may move to August as appropriate). N I S T s m a r t g r i d p r o g r a m

17. TE Co-sim Abstract Component Model A detailed technical specification that can be faithfully implemented on one or more simulation platforms comprising: A set of model components with specific minimum interfaces Any interface can be extended as needed for any TE Challenge Case Core components can be combined and hide internal interfaces A canonical simulation that allows the set of components to be orchestrated in a simulation Minimal or extended models can be substituted for any component(s) and can simulated by the same experiment controller A reference grid and scenario A defined set of grid nodes, resources, controllers, and transactive agents and market simulation to provide a baseline for comparison A minimum core set of analytics based on the data provided through the canonical simulation 17 N I S T s m a r t g r i d p r o g r a m

18. Notional Topology of a TE Simulation Distribution System Operator Transactive Broker - Aggregator Grid Grid Bulk Aggregator TA Controller Controller Generator 2 Microturbine 3 Industrial Load Grid Industrial Customer Auction Storage Market Maker Residence Load Retail Customer 1 Building/Home with Automation System Microgrid PCC Grid Link Resources Key Transactive Appliance Resource: Load Resource: DER Grid + Controls Weather Controllers Manages Transactive Agent Local Controller Supervisory Controller Transactive N I S T s m a r t g r i d p r o g r a m

19. Core Modeling Components of Abstract Component Model class Transactive Energy Components Core Components BaseModelComponent BaseModelComponent LocalController SupervisoryController {1..*} {1..*} LocalControl ResourcePhysicalStatus + actualDemand: float [0..1] + demandLimits: PowerRatings [0..1] + downRamp: PowerRampSegmentType [0..*] {ordered} + upRamp: PowerRampSegmentType [0..*] {ordered} + locked: Boolean [0..1] + status: LoadStatusType [0..1] + resources: Resource [0..*] ResourcePhysicalStatus TA WeatherData 1..* 1 Weather 1 BaseModelComponent Resource {1..*} ResourceControl + gridNodeId: GridNodeId + current: Current + power: Power + impedance: Impedance + phases: Phases + voltage: Voltage + status: boolean ResourcePhysical 1..* WeatherData BaseModelComponent TransactiveAgent BaseModelComponent Grid {1..*} TA Grid + Nodes: Link [1..*] WeatherData WeatherData Specializations Load Generator GridController Auction 19 N I S T s m a r t g r i d p r o g r a m

20. sd Base TE Experiment Scenario Common Platform Canonical Simulation Experiment Manager Weather GridControler Grid Resource 1..* LocalController 1..* SupervisoryController 1..* TransactiveAgent 1..* (from (from (from (from (from (from (from TEComponents) (from TEComponents) TEComponents) TEComponents) TEComponents) TEComponents) TEComponents) TEComponents) Initialize(float) Initialize(float) Initialization may be a sequence of messages to each object. Initialize(float) Initialize(float) Initialize(float) Initialize(float) GridControl(GridControl) par TE experiment loop Physical simulation of load/generator attached grid. The message lines in this case may be messaged or actual physical simulation. ResourcePhysicalState(ResourcePhysicalState) [Physical] GridVoltageState(GridVoltageState) ResourcePhysicalStatus(ResourceStatus) ResourceControl(ResourceControl) [Logical Controller] Logical simulation of controller action on its managed loads and generators. Messages in this case may be directly messaged or may be messaged in conjunction with a communications simulation such as NS3 or Omnet. Weather(Weather) Weather(Weather) Weather(Weather) Weather(Weather) Weather(Weather) SupervisoryControlSignal(SupervisoryControlSignal) ResourcePhysicalStatus(ResourceStatus) [Transactive] loop Settle Tender(Tender) Tender (Tender) Tender (Tender) Quote (Quote) Transactive time step. Quote (Quote) Note that self-links for TransactiveAgent imply sharing among the various Transactive Agents in the scenario. Transaction (Transaction) Transaction (Transaction) 20 N I S T s m a r t g r i d p r o g r a m

21. Baseline Use Case X10 for each phase 30 houses divided among three phases on one distribution transformer. AS ABC The distribution system has one uncontrollable load (Resource) and one source of bulk power (Resource). BS There is a weather feed of TMY3 Data for a single locale (Weather). CS ABC Each house has: A solar panel (Resource) A controllable load HVAC (Resource) A non-controllable load (Resource) A home automation system (SupervisoryController) A thermostat (LocalController) A transactive agent (TransactiveAgent) {Desired Setpoint, State} Grid {Setpoint} Weather {TMY3 Data} {Quote: Cleared Price, Marginal Quantity} {Tender: Bid Price, Bid Quantity, State} Resources Nodes LocalController Links Logical Connectors Transactive Agents Bulk Power PV Panel (+inverter) Meter (triplex) Transformer Power Flow Thermostat Bidding Controller Node (triplex) Dummy Grid Load SupervisoryController Triplex cable Data Weather Auction Controllable Load (HVAC) Node (three-phase) Uncontrollable Load 21 N I S T s m a r t g r i d p r o g r a m

22. Traceability of Instance Model To Abstract Components class Common Component Inheritance Resource Resource BaseModelComponent Transactive Energy Components: :Generator Transactive Energy Components::Load Transactive Energy Components:: TransactiveAgent {1..*} ZIPLoad Unresp_load HVAC_Load Solar Transactive Energy Components:: Auction Transactive Energy Components::Weather Gridlab-D source inside existing object ZIPLoad_controller Null_Controller HVAC_Controller Inverter Auction Climate House Gridlab-D Model Components BaseModelComponent BaseModelComponent Transactive Energy Components:: SupervisoryController Transactive Energy Components::LocalController {1..*} {1..*} N I S T s m a r t g r i d p r o g r a m

23. Metrics that can be Extracted by Analytics Component Through the course of the experiment/simulation the following data can be extracted from the message exchange: Grid power flow and voltage states Load profile as consumed by all loads Generation profiles as produced by all solar panels Aggregated loads by household Price negotiations and exchanges Realized pricing coordinated by loads and generators 23 N I S T s m a r t g r i d p r o g r a m

24. Common Metrics Name gridPower loadProfile generationProfile aggregatedLoadsByHousehold Type Power Energy Energy Energy Notes Power provided by the Grid. Power flows at each grid node. Energy consumed by each load. Generation by generator. Aggregated load by household. priceNegotiations realizeMarketPricing Tender Quote Sequence of all tenders. Realized Market price quotes. Metrics will be discussed in series of meetings Large collection of metrics defined for PNNL s TE Simulation Platform (e.g., voltage deviations outsides of ANSI, line overloads, etc.) N I S T s m a r t g r i d p r o g r a m