CIM Issues » WG14 Issues » WG14 Part 5 Issues

WG14, especially Part 9, would like to preserve the notion of "groups". While Part 9 has always supported group names, it never defined how groups are created and managed. Part 5 attempted to do this, but in doing so created the specialization "DER Groups". We would like to still see support for the mechanics of group maintenance (which spills over into Part 100), but see it generalized to support groups in general. We should support the notion of allowing one back office system to be the system-of-record that defines group membership, and another system (perhaps the AMI system) be the system that executes on that definition. This may involve quite a bit of communication as every device in the field is enrolled in the group, and verification of the enrollment is received from the implementing system. A change by the system of record to the group membership (perhaps due to feeder switching or some other activity in the field) could cause frequent churn to the group definition and frequent communication to maintain synchronization of the list as implemented in the field to the list as defined by the system of record.
Usecases include load control, but also meter reading, and other activities which are quite often internal to the AMI network. The process of downloading firmware upgrades to meters or NICs is often an internal matter to the AMI network, and risky to expose, but in theory, in the world of IoT, it could reach the point where a 3rd party firmware update must be delivered to groups of 3rd party IoT devices which share a common model and firmware version. The AMI network would view this activity as external to it. It is just delivering files that originate outside the network to devices that are outside the network. In summary, the grouping feature is integral to AMI networks, but the notion of allowing a system that is not the AMI Network be the system-of-record for the group definition allows it to be used by other systems (such as DR/DER).

One approach would be to modify Part 5 to merely be a document that defines generic group support. It could be a TR instead of an IS. Or the useful material could be extracted, modified, and added as an annex to another part such as Part 9.

Part 5 referred the reader to Part 9 as the mechanism for "End Device Controls". This still exists in Part 9. If the plan is to also annex the implementation of EndDeviceControls from Part 9 as well, then more discussion is needed, but I don't think we're opposed to the stated plan to annex the DER functionality from part 5. I suspect more discussion will be needed to describe how an aggregation will relate to specific devices in the field and how communication of a load shed command will be ensured.

[D Haynes, June 2024]

Per the modelling guide on the GitHub site:

General and <<Deprecated>> Stereotype Rules
This stereotype is recognised by the CIM UML validation and document generation tool and can be applied to any of the UML concepts defined below. The typical usage of the <<deprecated>> stereotype is for the purpose of preserving backwards compatibility for the normative, already published content, during a release or two, while indicating to the users that the item is likely to actually be removed in the future. This is a graceful means of phasing out obsolete or re-factored elements, and leaving some time to the users to provide implementation in terms of the new features replacing those marked with <<deprecated>>.