Many companies restrict and enhance the CIM classes that can be used in an application, using what are called profiles. For example ENTSO-E uses the Common Grid Model Exchange Specification (CGMES) which is a super/sub set of the CIM model.
This issue tracks the work necessary to support profiles.
Of interest:
provide a workflow for additional .eap model files to generate class files adhering to end-user profiles (see Issue #8) with user-defined namespaces and super/sub sets of the full CIM model that can be used at runtime as a "CIM version" - i.e. a dynamically loaded CIM version
provide a (text based?) configuration mechanism that simply limits the available classes from a full CIM set that are read by the CIMReader - all others being discarded - i.e. a dynamically loaded CIM subset
check if an 'electrical' configuration (of a CIM subset as above) which doesn't include Assets, Measurements, Locations, StateVariables, UsagePoint etc. allows the import of large CIM files on modest hardware
provide a generic mechanism, in the absence of a compiled set of classes from a profile, to read, store and export custom properties (in other namespaces) via a key-value map of "unknown/unparsed" attributes attached to existing classes
Many companies restrict and enhance the CIM classes that can be used in an application, using what are called profiles. For example ENTSO-E uses the Common Grid Model Exchange Specification (CGMES) which is a super/sub set of the CIM model.
This issue tracks the work necessary to support profiles.
Of interest: