CIM Issues #6328
Required usage of BusbarSection
IEC 61970-301, IEC 61970-452, IEC 61070-600
Description
Multiple requests received on lack of instructions if BusbarSection is a required class if a ConnectivityNode is a node (just for the connectivity purpose) or a busbar section.
There are multiple options how to solve this gap
- Option 1: state in 301 and/or 452 that "if a ConnectivityNode represents a busbar it is required that there is an instance of BusbarSection which Terminal is associated with this ConnectivityNode."
- Option 2: revisit the need of BusbarSection class. If we can make it a bit easier perhaps doing the following is better approach: 1) add a boolean ConnectivityNode.isBusbarSection, this shoudl be required in 452 2) see if if true we require BusbarSection class instantiated or not; if we want to keep it for compatibility we shoudl write a constraint in 452 to require BusbarSection is the boolean is true and we can validate this.
I will put an issue in the IEC on this, but we need to see what the next steps will be within ENTSO-E. The BusbarSection class is in both v2.4 and v3 and it is a matter to say that the usage of it is required in some cases. In a way this is the main purpose of this class anyway. the point we need to state is that it is important to use it.
Decision
07-Feb-2023 Discussed in weekly meeting:
o New wording proposal needed for the UML (simplify BusbarSection class). Refer to BusSegment as an example.
o While we are add it the description for Junction must be updated as well.
o Strike from the note the last sentence on BusbarSection: “Typically, BusbarSections and Junctions are represented by different symbols on diagrams.”
o Additionally, updates to the 301 to clarify will need to be added (in addition to what is in the UML). Add what Chuck has provided as well. Refer to: CIM Issues #5868: New BusSegment for busbar modeling - WG13 Issues - UCAIug Issue Tracking System as this is on the same topic (as this issue is about document.
o Close both this issue and #5868 when completed.
o Target for review in next week’s meeting for approval before applying to the UML.
Updated by Richard de Groot almost 2 years ago
A choice for Option 2, doing away with BusbarSection, requires an alternative for busbar specifics. These include at least:
1. the attribute ipMax (used in e.g. short-circuit studies),
2. the relationship to VoltageControlZone (used for modelling centralised voltage control?),
3. busbars typically also have a rated thermal short-circuit current and rated thermal short-circuit current duration. These do not seem to be present in CIM yet.
Should these items also be moved from BusbarSection to ConnectivityNode? Or do they validate the separate class?
Updated by Todd Viegut over 1 year ago
Option 1: This is the minimal work that should be applied.
Option 2: There are preliminary questions that must be answered. It would be more ideal to have the isBusbarSection boolean and not use a BusbarSection class. However, if we need to have a Geo Location associated with the BusbarSection then that would require we keep the class (i.e. Location is association with PSR which BusbarSection inherits from).
Also...for option 2...Richard highlighted:
A choice for Option 2, doing away with BusbarSection, requires an alternative for busbar specifics. These include at least:
1. the attribute ipMax (used in e.g. short-circuit studies),
2. the relationship to VoltageControlZone (used for modelling centralised voltage control?), (THIS ITEM HAS BE RESOLVED by Chavdar's CIM18v10 updates. It has been deprecated.)
3. busbars typically also have a rated thermal short-circuit current and rated thermal short-circuit current duration. These do not seem to be present in CIM yet. (IF WE KEEP BusbarSection the class can be leveraged to model these attributes. Alternative to this #3 is: apply #1, keep this class and then us the isBusbarSection boolean)
Should these items also be moved from BusbarSection to ConnectivityNode? Or do they validate the separate class?