CIM Issues » WG16 Issues

There should be a clear understanding of the different between

MarketManagement:Domain = An area of activity defined within the energy market
MarketCommon:AggregateNode = An aggregated node can define a typed grouping further defined by the AnodeType enumeration. Types range from System Zone/Regions to Market Energy Regions to Aggregated Loads and Aggregated Generators.

To me, these concepts seem very similar if not identical. The history is relatively clear, the AggregateNode when applied a wholesale LMP-style markets is a collection of physical priced notes, for example a region over which little constraints appear. The Domain is used for wholesale markets in Europe where the regions are less tied to the grid model.

When viewed in the context of physical grid-connected devices, the grid location must be know for studies and operational scenarios, so understanding this association is important. Equally important is to understand how virtual resources can be aggregated, i.e. constrained to either an AggregateNode or a Domain.

More opinion: AggregateNode is accurate, but not intuitive. Typically people refer to these are market Zones, Bidding Zones, Bidding Regions, etc. Starting from scratch, I would propose Zone as a class name. Domain is overloaded (there can be data domains, time domains, etc.), but it is a bit better than AggregateNode from a "what does this mean to humans" perspective.

So, this issue could be resolved in many ways.

(1) If truly different concepts, improving the descriptions would go a long way. For example, not that resources are "attached" to an AggregateNode from a model perspective but flex services are associated to Domains. I have problems with what that means logically, but if that is the answer - updating the descriptions will help.
(2) Perhaps there is an association needed, especially in the case of option (1) perhaps we also need to know both the AggregateNode and the Domain(s).
(3) If the same concept, consider harmonization. Domain has a implementation history that should be considered, so perhaps deprecating AggregateNode, and expanding Domains properties and associations to include those of AggregateNode could work - essentially replacing AggregateNode with Domain for some future edition.
(4) Something I have not thought of yet.