[OASIS Issue Tracker] Commented: (EMIX-382) Are the PowerConstraints in the correct Schema?

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/EMIX-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25263#action_25263 ] 

Girish Ghatikar  commented on EMIX-382:
---------------------------------------

In my opinion the constraint definitions must be completely independent of implementation and must be made much simpler. The constraints are more applicable to EI and within DR markets (yes, other price products may use part or all of it). We have to be consistent on how and where:

1. We define it (based on where it's being used/applied).
2. How we apply it to a specific requirement (for me price and DR are dependent requirements and not independent). 
3. Cite some examples of how such a consistent definition makes its way to different service offerings (as opposed to market products). 

We also discussed the other part in depth earlier that asset (or its definition) doesn't belong in EMIX (and is EI specific). The constraints are also applicable to assets and not just resources. The consumer and the market will determine where and how it can be applied. We're just providing the standardized mechanisms for their use. 

Below is some of the discussion we've had (with my comments) to the EI TC mailing list (and the discussion was brought to EMIX now):

I look a this differently and much simpler requirement. The constraints we want to add are purely based on the need of the markets (and defined by them). Of course, there will be many more that the future markets will determine and that is part of every standardization process and most of the requirements included in EI -- things evolve as we move on. Here, wer're defining the requirements for both current and future market needs.

The real question is what are the minimum set of requirements that a market needs right now? 

From the ones you've suggested, I would say (plus more) the following as it relates to a specific program (or universal) per resource (not sure if it has to go all the way to the asset): 

- Availability Schedule (includes both date/time such as black-out dates/times)
- Minimum Notification Time (prior to the event)
- Maximum Run Time (duration/window during the event)
- Maximum participation days for consecutive event days

There might be others that the TC may determine are necessary. 

> Are the Power Constraints in the correct Schema?
> ------------------------------------------------
>
>                 Key: EMIX-382
>                 URL: http://tools.oasis-open.org/issues/browse/EMIX-382
>             Project: OASIS Energy Market Information Exchange (eMIX) TC
>          Issue Type: Improvement
>          Components: schema
>    Affects Versions: wd23
>            Reporter: Toby Considine
>            Assignee: William Cox
>
> We have three schemas in EMIX, EMIX, Power, and Resource. The constraint base type and the market independent constraints and requirements are part of EMIX. The EMIX schema has no power-specific attributes, including, in particular, no power-specific constraints. The constraints in the EMIX schema are all tied to duration, schedule, or economic requirements. These would all apply as well to steam or the natural gas, or for that matter, to Apple Orchards and to Seafood.
> We have four specific extensions to the Constraints class for use in power markets. These rely on the attributes defined in the power schema. These are:
> MinimumLoad	Constraint on Minimum Load that a Resource can maintain (powerQuantity)
> MaximumPower	Constraint on Maximum Power available from a resource (powerQuantity)
> MaximumEnergy	Constraint on Maximum Energy available from a resource (energyQuantity)
> MinimumLoadReduction	Minimum request for load reduction (e.g., MW rating of a discrete pump) (powerQuantity)
> These constraints are currently in Resource. Some recent comments have suggested that they should be in Power instead. Committee discussion and guidance would be welcome.
> Note: I have at several times considered whether Resource should be combined in toto into Power.xsd, but backed off when there were so many discussion of using resource.xsd inside ASHRAE SPC201.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira