CIM Issues #6147
Updated by Pat Brown 11 months ago
Currently, the modelling use of an unbalanced (tank-based) TransformerMeshImpedance and TransformerCoreAdmittance to express transformer can be accomplished impedances in unbalanced network models also requires TransformerEndInfoobjects and, in the most rational approach, also a variety of ways, using a multitude of combinations of TransformerTankInfo object. The need for the xxxInfo classes and associations. The number of possible alternatives is an impediment to interoperability. A number because some of the classes used in describing transformers for network modelling purposes required attributes are also resident not defined in the 61968 package, not TransformerTankEnd class –they exist only in the 61970 package, despite TransformerEndInfo class. Interestingly, the fact information model has a PowerTransformerEnd class (a ‘sibling’ of the TransformerTankEnd class) that they were designed to support network analysis, not asset management, use cases. This issue suggests has the articulation required attributes.Development of a comprehensive, cohesive an approach to tank-based transformer modelling which ‘direct impedance’ modeling for unbalanced models that doesn’t require use of xxxInfo classes would accomplish be helpful. The conversation should take place within the following: • Support the modelling larger context of tank-based transformers in strictly electrical terms • Support addressing the modelling of tank-based transformers using test results • Support the definition of ‘catalog’ information of both kinds of modelling (electrical terms and test results) • Align with the current balanced (non-tank-based) transformer modelling described by 61970-301 and -452 • Augment the current non-tank-based modelling need to allow modelling of those transformers with test results The net outcome support ‘electric parameter only’ unbalanced grid model data exchange in general. There is anticipated a similar issue raised below related to significantly leverage existing classes, attributes TapChanger and associations. Likely changes include a few new associations TapChangerInfo.(Note that clarify (and there is no suggestion that support validation of) intended usage, perhaps some moving of attributes from one class for ‘device datasheet’ distribution grid modeling is not needed. This just suggests that consideration also needs to another and be given to the move provision of a number of classes from the 61968 package to the 61970 package. modeling in ‘electric parameter’ terms.)