Re: [energyinterop] Groups - ei-cts-v1.0-wd01 Schemas.zip uploaded

Ok, I have reviewed what I sent by the light of day. Some of the issue is that I am pointing out holes in CTS as contributed, by letting the TC decide.

CTS as used in the current CTS software trades product "1". But what is product 1? Assuming it is one hour of energy, does the market also have 15 minutes of energy, or 1 minutes? How would the device know?

One of the first charges of the EPRI Smart Grid team was to make the trading messages clear, to not require special knowledge. That was the reason EMIX was developed. If we are trading "product 1" we fail that charge.

Does the market include any ancillary services? 

Does the market include Congestion, or Transport?

No way to know. 

If Transport is there, is it #2 or number 3?

As I see it we can go one of two directions. 

(1) We can include an EMIX payload in each and every CTS message.

(2) We can describe a way to look up what (1) means.

But there's more...

If CTS is to support Plug and Play markets, there needs to be a big white board on the wall where what's for sale is listed. Even if it is only power, there are the various granularities. Listing only temporal granularities. one can see a market having:

1 hour power

10 minute power

1 minute power 

as three products. If that is the case, there is no point in submitting a 15 minute tender into the market--it will never be matched

And lest someone think that 1 minute is too small, one of the larger consumer TE applications is for voltage regulation, is cover a quarter of the US, and
 it started as a 4 second market and is now, if I am not mistaken, a 2 second market. 

That white board is referred to in EMIX as the Market Context. 

It is not difficult to imagine several interactions with the market context that go somewhwhat like

A) What energy products do you trade here

MC) we have 1 hour and 1 minute

Just as easily it could be

A) What products do you trade here

MC) here is a bunch

A) I don't know what most of those are, so I am discarding everything but the three energy products

Digging a little deeper, is there a renewable flag on some of the tenders? Can I ask to only buy on the renewables market? That introduces the Warrants.
 Warrants are optional, but MAY include information that distinguished the Energy from some other Energy. Do we need a list of the Warrants that are understood in this market?

Market mechanics are out of scope, but one can imagine a tenderer that asks for "Renewables or nothing". Alternately, one can imagine a tenderer that does
 not care, but would accept renewables if it met the price tendered.

The long and the short of this is that we, as a TC, should walk through and declare what is in and what is out of scope as we tighten this profile. Those
 extra elements Dave observed are elements that we need to decide if we want to restrict from EMIX. (As scoped right now, all of EMIX is in, because we are only profiling EI)

tc   

 

From: Considine, Toby <>

Sent: Monday, February 22, 2021 2:46 PM

To: Holmberg, David G. (Fed) <>;  <>

Subject: Re: [energyinterop] Groups - ei-cts-v1.0-wd01 Schemas.zip uploaded

 

Sounds like I scooped some extra trash up when I bundled the eml in that directory.

Let me look at it. On conference calls until after 6.

tc

From: Holmberg, David G. (Fed) <>

Sent: Monday, February 22, 2021 12:39 PM

To: Considine, Toby <>;  <>

Subject: RE: [energyinterop] Groups - ei-cts-v1.0-wd01 Schemas.zip uploaded

 

Toby, Bill, all,

 

(1) Bill, I didn’t see video links to EML videos that were going to be posted for the TC. I also couldn’t find them on the eml website.

(2) All, please review the 
ei-cts-v1.0-wd01.pdf for discussion on Thursday EITC call.

(3) I’m looking through the eiclasses.xsd (link below). Some things we might discuss:

I notice that there is eiMarketContext, but also eiMarketExpectations and eiMarketRuleset. I don’t remember talking about the latter two, or I would expect them to be inside of market context.

Why is simpleLevels in here? Also optType?

Also registration and delivery—I thought the initial scope was simply tender and transaction, whereas registration and delivery are out of band. For discussion I guess.

For registration, the SEPA ESI TF is working to extend OpenADR for auto-registration.

Do we (collectively) want to use eiQuote? I know we have discussed the option of simply using eiTender and marking it as not firm, but I don’t see any “not firm” element in eiTender.

 

 

Thanks,

David 

 

From:  <>
On Behalf Of Toby Considine

Sent: Tuesday, February 16, 2021 8:15 AM

To: 

Subject: [energyinterop] Groups - ei-cts-v1.0-wd01 Schemas.zip uploaded

 

Submitter's message

All Schemas from Energy Interoperation, EMIX, and WS-Calendar are included for ease of review.

-- Toby Considine 

Document Name:
ei-cts-v1.0-wd01
 Schemas.zip

Description

Schemas for EML-CTS WD01. All Schemas from Energy Interoperation, EMIX, and

WS-Calendar are included for ease of review. 

Download
 Latest Revision

Public
 Download Link

Submitter: Toby Considine

Group: OASIS Energy Interoperation TC

Folder: Standards

Date submitted: 2021-02-16 05:14:14