1 / 18

Interaction Architecture for EITC

Interaction Architecture for EITC. W. T. Cox 2010-05-04 Version 4. Zoom in on Interoperation. Recursive pairwise relationship Participant implements aggregator interface to distribute events to its own participants

baxter-mcgee
Download Presentation

Interaction Architecture for EITC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Interaction Architecturefor EITC W. T. Cox 2010-05-04 Version 4

  2. Zoom in on Interoperation • Recursive pairwise relationship • Participant implements aggregator interface to distribute events to its own participants • Compose appropriate security, reliability, and interaction model as appropriate for each interoperation link • Names are not set; intended to be more evocative than Gale Horst’s Virtual End Node and Resource Energy Controller (VEN and REC) but the concept is the same. DREvents Aggregator- Operator Signals and responses Participant- Operator

  3. ISO Aggregator Store HQ Store Location Aggregator Store HQ Store Location Store Equipment Abstract to Concrete(1)

  4. ISO Aggregator Industrial Microgrid Industrial Facility Aggregator Industrial Microgrid Industrial Facility Process Control Abstract to Concrete(2)

  5. DR Event Services Determination of nature and details of DR Event The direction shown is from initiator to service. Response or ACKs not shown NOTE: OpenADR names assume an intermediary, the DRAS, where information is stored Aggregator- Operator SetDrEventFeedback… CreateResponseSchedule… SubmitDrStandingBid… GetAggregatorDrEventStatus… Participant- Operator InitiateDrEvent ModifyDrEvent GetDrEventInformation CancelDrEvent

  6. Changes in This Version • Internal-only services have been deleted • From D1 • DrEvent services kept • See Spreadsheet Tab D3 • Total 25 services so far • 5 invoked by Aggregator on Participant • 21 invoked by Participant on Aggregator

  7. Aggregator on Participant • 5 invoked by Aggregator on Participant • Initiate, Modify, Adjust, CancelDrEvent, GetDrEventInformation • Explicit, not implicit, reliability signals • Which invocations send price/product? • Naming needs work—not all are DR • Some will be price • Some will be (e.g.) usage/load information (2 way)

  8. Participant on Aggregator • 21 invoked by Participant on Aggregator • 2 Event Feedback • 3 Response Schedule • 5 DR Bid Services • 2 Status Services • 1 DR Program Services • 2 Participant Management Services • 3 Program Constraints Services • 3 OptOut State Services

  9. Next Steps (1) • Names that are more indicative of content • Detailed message content • Application ACK and Reliable Messaging • Consider using WS-Addressing, WS-Context • Delivery of other messages via EI? • Text messages as in some designs?

  10. Next Steps (2) • Factor into type of communication/interoperation • DR (reliability signal-related) • Price+Product Def communication • Other Communications, e.g. • Load (History, Present, Future) • Usage (History Present, Future) • Details on each service family • Location of information • Operations

  11. Previous Slides • Not changed in this version

  12. A Slice Through the Notification Tree DREvent Participant- Operator Participant- Operator Participant- Operator Participant- Operator Aggregator- Operator Participant- Operator Participant- Operator Participant- Operator Participant- Operator Participant- Operator Participant- Operator Participant- Operator Participant- Operator ISO Aggreg Agg Client Industrial Pk Tenant

  13. Protection and Reliability More Reliable Less Reliable More Protected Less Protected Fewer Per Layer More Per Layer DREvent Participant- Operator Participant- Operator Participant- Operator Participant- Operator Aggregator- Operator Participant- Operator Participant- Operator Participant- Operator Participant- Operator Participant- Operator Participant- Operator Participant- Operator Participant- Operator ISO Aggregator Aggretator Client Industrial Park Tenant

  14. ISO Issues and Requirements (1) • ISO issues with varying security and reliability/confirmation of delivery requirements • Application to non-California markets and interactions • Factor out tariffs/contracts • Notification of reliability events is key to ISOs • Distribution is also key to ISOs • Price communication is relatively unimportant to some ISOs • Price quote/closing price stream is important and done today (with no standard format/delivery mechanism) • EMIX as the price quote stream

  15. Requirements & Conclusions • Factor out tariffs/contracts • Price communication must be in the spec • Price communication is not only via the spec • EMIX as price quote stream, various transports • Need requirements in citable format for detailed analysis • IRC, NAESB, EIS Alliance

  16. Participant/Real Estate Notes • Real estate managers and landlords want a way to distribute events to tenants and/or separate owned properties • Price distribution appears to be a requirement • Needs discussion/analysis • Part of signaling is simplest, allow for other delivery • Consistency of approach allows application to recursive ownership and notification • Developer/REIT owns 100 office parks. Each office park gets signal, distributes to tenants. • Tenants or office park manager can distribute to ESIs at all levels

  17. MicroGrid Notes • Each ParticipantOperator is a MicroGrid control access point (associated with MicroGrid ESI) • Fit nested or unions of MicroGrids into the picture on slide 3 • Notification to MicroGrid-contained participants has differing security/reliabilty requirements

  18. Summary of Application of EI • Signal notification paths have varying requirements • Must be able to apply/compose additional configured solutions • Compose WS-Reliable Messaging • Compose WS-Security components • Compose other needed technologies (undetermined) • Factor • Price Signals (with multiple delivery paths) • Reliability Signals (single secure and reliable path) • Environmental Signals (similar to Price) • All need individual links to have specific characteristics • Non-repudiation, privacy, confirmed/signed source • Reliability, app-level or transport-level ACK • Probably the same at each level (for each Aggregator-Operator instance)

More Related