CIM Issues #6745

Need for consistent approach for Market Products

Added by Scott Coe about 2 months ago. Updated 30 days ago.

Author/Contact Info:
Scott Coe
Base Release:
Solution to be Applied To:
Solution Version:
Solution Applied By:
Completion Date:
CIM Keywords:
Breaking Change:
Breaking Change Description:
CIM Impacted Groups:
Originally Closed in Version:
Origination Date:
Origination ID:
Originally Assigned To:


Market Products are not used consistently in the CIM because market products are not really consistent across markets...

Energy is the universal commodity; however, even when considering universal grid support products the names vary. In the North America, they call the load frequency control the Regulation product, but in Europe is is Secondary Reserve. Standby/emergency reserve products are more varied. Tertiary Reserve in Europe is split into Synchronous and Non-Synchronous Reserve in the North America. But in even in North America, there is inconsistent usage. PJM calls it Synchronized/Non-Synchronized, MISO and SPP have Spinning and Supplemental, NYISO/ISO-NE/CAISO use Spinning and Non-Spinning, and finally ERCOT has Responsive and Non-Spinning.

One of the oldest market enumerations, MarketProductType does not follow the typical format. We have: EN, RU, RD, SR, NR, RC, LFU, LFD, REG, RPU, CO2e, RMU, and RMD. Changing to Energy, RegulationUp, RegulationDown, SynchronousReserve or SpinningReserve, NonSynchronousReserve or NonSpinningReserve, ReliabibilityUnitCommitment, LoadFollowingUp, LoadFollowingDown, CarbonDioxideEquivalent, RegulationMileageUp, and RegulationMileageDown would break things.

Then we have a similar enumeration: ResourceCapacityType. RU, RD, SR, NR, MO, FO, RA, RMR which map to RegulationUp, RegulationDown, SynchronousReserve or SpinningReserve, NonSynchronousReserve or NonSpinningReserve, MustOffer, FlexibleOffer, ResourceAdequacy, and ReliabilityMustRun. Clearly a different use, but some of the concepts here overlap.

Finally, the most recent is ResourceCertificationKind which allows us to flag when a resource is certified to provide a service. Here the enumeration is properly formatted (all but one entry, that is) and again have a strong correlation to products: RegulationUp, RegulationDown, SpinningReserve, NonSpinningReserve, ReliabilityMustRun, BLACKSTART, DemandSideResponse, SynchronousCondenser, ReliabilityUnitCommittment, Energy, Capacity.

Proposed Solution

As wonderful as it would be to standardize terminology here, that may be asking too much especially with major differences in terminology between North America and Europe. When we get to distribution/retail products, the challenge is effectively impossible. Increasingly the Market Package will be used for Non-Market implementations and even the term is misleading. I would propose that we gradually move towards the term "Grid Service".

We we add a new attribute of "gridService" to any class that needs to identify what commodity is being delivered to or consumed from the grid this could work. If we jettison the utopian dream of a universal enumeration and make it a string with comments, we recommend the string utilize common service in the documentation. I would propose that list be large and offer some regional variations:

Grid Service Recommendations:
- Energy
- Capacity
- PrimaryReserve
- SecondaryReserve
- TertiaryReserve
- Ramping
- SynchronousReserve
- NonSynchronousReserve
- VoltageSupport
- Restoration

Alternately, we could enshrine these in an enumeration and have an string option to include in the profile if one would like to deviate from the standard. If that were the case, I would expand the list slightly, e.g. add SpinningReserve and NonSpinningReserve even though these are the same as Synchronous and NonSynchronous Reserve, to help minimize the times a local extension is required.

Additionally, I recommend we add a direction to the Grid Service as a separate field. Many resources can provide one one "side" of the delivery, for example a load may be able to provide energy reduction (demand response), but not energy increase. Rather than separate out each grid service, and enumeration called gridServiceDirection could be used with the following:

- BiDirectional
- Injection
- Withdrawal
- Increase
- Decrease

I suggest the two "flavors" because some products naturally make sense with one and not the other. For example, Voltage Increase makes sense but not really Voltage Injection. Energy, on the other hand, makes sense ash Energy Injection and less so (although not entirely with Energy Increase) - I think worth a debate. I do recommend against anything which can be viewed differently from the grid and customer perspective, like "import" and "export" or "in" and "out". A battery might export to the grid, but the grid operator is importing power from the customer. These "which side of the meter am I sitting" issues can lead to confusion and errors in exchanges.

If this idea is not popular, we can always revert back to triplicating each service, e.g. RampingUp, RampingDown, and Ramping (for the case where the service requires both directions and does not differentiate pricing based on direction).

We also need to consider similar constructs already established, of which there are more than I expected:

- flowDirection (string)
- FlowDirectionType (enumeration 'forward' and 'reverse')
- FlowDirectionKind (large enumeration focused on real/reactive power quadrants)
- RelativeDirectionKind (enumeration 'up','down','upAndDown' and 'none')
- BidDirectionKind (enumeration 'up', 'down', 'upAndDown' and 'stable')
- ScheduleKind (enumeration 'generation', 'load', 'loadIncrease', 'loadDecrease', and soon 'genrationIncrease' and 'generationDecrease')
- ComDirectionKind (enumeration 'fromDevice', 'toDevice', and 'biDirectional')

This last one is close to what I propose, but is awkward to use with the "Com" in front. But it does sorta make sense with the service coming from the device and/or going to the device, so I could see us using that with service; although the natural use would rather be 'fromResource' and 'toResource'.

Hopefully something I propose here will resonante and spark some ideas from the group for something perhaps better than I am proposing...

Related issues

Related to Market Management - CIM Issues #6293: Add energyFlowCategory (string) to the AccountingPoint classOpenActions

Updated by Scott Coe about 2 months ago


- Europe has changed their terminology and moved away from the Primary, Secondary, Tertiary terms stated above. But this actually solidifies the point I am making.

- Several of my "direction" options listed above are informational (RelativeDirectionKind and BidDirectionKind) so need to be reviewed before using. This will also be discussion on the Grid side related the emerging ENTSO-E and EU Network Codes (perhaps Balancing Network Code?)


Updated by Becky Iverson about 2 months ago

  • Related to CIM Issues #6293: Add energyFlowCategory (string) to the AccountingPoint class added

Updated by Becky Iverson 30 days ago

  • Status changed from New to Open

Also available in: Atom PDF