Project

General

Profile

CIM Issues #7009

Addition of EnergyCharacteristics to MarketManagement

Added by Jan Owe about 2 months ago. Updated about 11 hours ago.

Status:
New
Priority:
Normal
Author/Contact Info:
Bhagyashree Wahie, Jan Owe
Base Release:
Grid18v10_Enterprise14v03_Market04v17
Solution to be Applied To:
Solution Version:
Solution Applied By:
Completion Date:
CIM Keywords:
62325-MarketManagement
Breaking Change:
Breaking Change Description:
CIM Impacted Groups:
WG16
Requestor:
ENTSO-E
Standard(s):
Version:
Clause:
Sub-Clause:
Paragraph:
Table:
Originally Closed in Version:
Origination Date:
09/26/2024
Origination ID:
BW_20240327_01
Originally Assigned To:

Description

The requirement originates from the EU Implementing regulation (EU 2023/1162) for access to metering & consumption data.
The new class will cover information that is relevant both for MarketEvaluationPoints, but also for time series, i.e. the suggestion is then to put this information into a separate class and not to put attribute(s) into both classes. Another maintenance request under preparation may result in further additions of attribute(s) to the new class.
The here suggested new attribute flowDirection is in the EU implementing regulation called "Direction" with the following description "Flow direction metered by the metering point. This can be either solely production, consumption, or combined."


Files


Proposed Solution

  • The MR suggests adding the EnergyCharacteristics class to MarketManagement and associate it with Series and MarketEvaluationPoint. See furhter attached PDF file.

Additional background from 6745 issue for consideration:
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'


Decision

10/10/2024: Considering use of enumeration ScheduleKind if the name of the enumeration could be changed to remove the term "Schedule". Or make use of the existing FlowDirectionType which currently has "Forward" and "Reverse" to add in all enum values from ScheduleKind (generation, load, loadIncrease, loadDecrease, generationIncrease, generationDecrease). Possible to add additional enum values of production, consumption (duplicates of generation, load). No decision has been made to date. Karyn and Bhagyashree will propose an updated request.

2024/10/31: Notes:
Change ScheduleKind enumeration name to CommodityDirectionKind;
CommodityDirectionOptionsKind
- productionOnly
The commodity is allowed to flow into the grid only, for example a dedicated generation source

- consumptionOnly
The commodity is allowed to flow out of the grid only, for example a dedicated load

- combinedConsumptionProduction
The commodity may flow in either direction at any given time, for example an energy storage system or a load with embedded generation

Description for what types of commodity flows are allowed at a given point on the grid.

CommodityDirectionKind
- production
- consumption
- productionIncrease
- productionDecrease
- consumptionIncrease
- consumptionDecrease

Description for the current state of a commodity flow at a given point on the grid.
Note: Review existing descriptions for enum value in ScheduleKind.

11/7: Jan, Karyn, Bhagyashree - Plan to propose UML model updates using the above two distinct enumerations.
11/21: Bhagyashree, Jan - Presented the use of the two new enumerations. Questions around the use of a new class with 0..many cardinality vs incorporating the attributes into an existing class.


Release Notes

**

#1

Updated by Becky Iverson about 1 month ago

  • Decision updated (diff)
  • Release Notes updated (diff)
#2

Updated by Becky Iverson about 1 month ago

  • Proposed Solution updated (diff)
  • Decision updated (diff)
#3

Updated by Becky Iverson 21 days ago

  • Decision updated (diff)
#4

Updated by Becky Iverson 21 days ago

  • Decision updated (diff)
#5

Updated by Becky Iverson 14 days ago

  • Proposed Solution updated (diff)
  • Decision updated (diff)
#6

Updated by Becky Iverson about 11 hours ago

  • Decision updated (diff)

Also available in: Atom PDF