CIM Issues #7025
Standardized the use of flow/direction across working groups and CIM packages (Grid, Enterprise, Market)
Description
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...
Files
Decision
Notes from TF16 discussions:
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.
Updated by Svein Olsen 3 months ago
I think the complete premise is incorrect in regard to the grid. The grid is in principle complying to the Kirchoff's law and operating on a given time resolution. Grid must describe the capability of the equipment as best as possible. Direction is in principle solved by active power -p can be positive or negative and where flow is important, we are using the load convention so that a unit producing power will be negative and a unit consuming is positive. The grid must also handle reactive power balance. We have in the grid side many equivalences, e.g. EnergyConsumer. With more production in the distribution grid, these equivalents cannot be used any longer.
Market concept is simplification that cannot be translated one-to-one to operational concept. they might also vary from maket to market. The grid concepts are driven by the type of equipment that are available in the grid and are less affected by market regulation.
I agree and support that we should aligned market concept and operational concept. To go to a generic terms like Commodity - you are really open the world. If we are listing the most common group of commodities we have Energy, Metal, Agricultural.... For grid we really need to know if we are talking about Energy or Power - let us focuses on those and let someone deal with soybeans...
Updated by Todd Viegut 3 months ago
19-Feb-2025: Weekly TF13 modelling call
Reviewed this joint issue during our weekly call and the commentary provided by Svein. Feedback to TF16 is that we agree with the goal to harmonize market and operations. Need to discuss though the proposed decision. We have two very different perspectives that warrant deeper discussion to arrive at alignment.
Updated by Scott Coe about 2 months ago
Per Svein's comment, I agree our commodities are limited. Commodities could be Real Power, Reactive Power, Real Energy, or Reactive Energy. But there are also commodities - especially at the distribution/retail level - that can be local. For example, the UK has adopted four flexibility services: Sustain, Secure, Dynamic, Restore. These happen to be, for the time being, Real Energy products. If anyone wants to work on this challenge, see Issue #6745. This is not the issue for commodity design.
This issue is focused on the way we describe the flow of any commodity. In other words, are you buying/injecting the commodity or are you selling/consuming the commodity. And is the quantity in the bid/offer/schedule/dispatch/settlement/etc. an absolute number or a relative number? For example, use 5 kW of energy or use 5 kW LESS energy. The flag to describe the flow should make sense for any basic quantity - again most commonly real energy or real power, but also reactive, standby capacity, etc.
There needs to be a buy term:
- Buy
- Purchase
- Consume
- Absorb
- Withdrawn
- Load
There needs to be a sell term:
- Sell
- Generation
- Production
- Injection
And each of those two needs three variants:
- An absolute target/setpoint
- A relative increase from target or current level
- A relative decrease from target or current level
Weighing the different options, I still recommend:
- production
- consumption
- productionIncrease
- productionDecrease
- consumptionIncrease
- consumptionDecrease
This works well for real energy (Energy Production vs Energy Consumption) and they also work nicely for reactive (Reactive Energy production vs. Reactive Energy Consumption).
My second choice is
- generation
- load
- generationIncrease
- geneationDecrease
- loadIncrease
- loadDecrease
Arguably, these work even better for real commodities (Energy Generation vs Energy Load), but when describing reactive they are a bit awkward as reactive is generally not describe as gen and load but as inject and absorb.
Note: There is a separate conversation about if a given point on the grid in a consumption point, a production point, or can be either. That is a separate discussion that optimally should be aligned with the result here, e.g. productionPoint, consumptionPoint, productionOrConsumptionPoint
Updated by Svein Olsen about 2 months ago
In the CIM_Grid18v14_Enterprise14v00_Market04v14 we have the following model in the informative package for Network Code extention:
We have the BidDirectionKind, isOffer (in contrast to isBid) we have RealEnergy on the bid Schedule and ActivePower on the PowerBidScheduleTimePoint.
Updated by Scott Coe about 2 months ago
The context for these flags include a number of scenarios all related to how services are procured from resources connected to the grid. These include flexibility services
- Bids/Offers (generally the use for dispatchable resources)
- Forecasts (generally the use for non-dispatchable resources such as loads and renewable generation)
- Clearing Results, Dispatches, and/or Schedules (all are basically the same concepts over different time domains)
- Actuals (which are often derived from metering or device-based measurements)
Updated by Svein Olsen about 2 months ago
In case I am not able to come after I done some more thinking. The following could be an alternative to production and consumption:
- Injection: When a market participant produces and supplies electricity to the grid.
- Offtake: When a market participant consumes or redraw electricity from the grid.