Learning Objectives
- Understand how to extend the CIM to handle gaps or new requirements
- Understand how extensions can be used to enumerate String classes without affecting the canonical CIM model
The CIM is a large and extensive information model, but since its inception it has been extended and expanded. Such extensions may occur due to IEC-led efforts to expand the CIM’s scope into new areas that are eventually integrated into the next revision of the standard; or utilities and vendors need to extend the CIM for their own projects to deal with new application areas or enhance the model to cover their own data requirements.
To better understand how and why a user may need to extend the CIM a number of simple examples will be used to illustrate how the model is extended. How these extensions are defined and stored is not standardized by the IEC or its working groups. For the purposes of these examples multiple-inheritance44 will be used, but the reader should understand this is not the only way to extend the standard and different vendors and applications have different approaches for marking and tracking additions to the UML.
44 Multiple inheritance is when a class may have more than one parent class and thus inherits attributes and associations from multiple parent classes. The CIM UML does not contain multiple inheritance and the IEC working groups deliberately avoid using multiple inheritance. There has been discussions and proposals for introducing it to the UML, but to date the modeling guidelines prohibit its use in the standard UML. However, it has been used for defining extensions to the model in a project perspective.
Accommodating Legacy Data
Adding a New Attribute
A simple example of adding an extension to the CIM is to use the situation of a utility migrating data from a legacy system to a new system that uses the CIM. The existing data structures have been mapped into the CIM, but there is a requirement to retain information about whether Equipment data originated in a legacy system or not.
This requires all instances of Equipment to have a flag fromABCSystem that is marked when the data originated in the legacy system (called ABCSystem in this example). This requirement extends to all subclasses of Equipment so the attribute must be added to the Equipment class and then inherited by the subclasses. The extended attribute must be marked as being an extension so that any exporter can either choose to ignore extended attributes or, if using XML, knows to put the extended attributes under their own namespace (so that an importer can correctly identify standard CIM data from the extended, non-standard data).
In Figure 10-1 the class ExtEquipment is added with the new attribute fromABCSystem. The existing, standard CIM class Equipment now inherits from its original parent, PowerSystemResource and from the ExtEquipment class. This means that all subclasses of Equipment inherit this new attribute, such as SynchronousMachine as shown in the example.
Adding New Classes
Extending this example, the scenario where two companies have merged and are integrating their systems into a single data model will be used. There may also be a requirement to retain a record of which system the data originated in. This could be added with another attribute on the class, however both the company and system the data originated in need to be modeled, as well as finding the source for an instance of Equipment needed to be able to navigate from the OriginalSource to all instances of Equipment that it originally provided.
To accomplish this a new class, ExtOriginalSource45 is added, with an association to the ExtEquipment as shown in Figure 10-2. This association is then also inherited by all subclasses of Equipment and by having a separate class it means that an instance of ExtOriginalSource need only be created once for each system that provided data and then shared between all instances of Equipment.
These extensions are examples of internal company/project specific extensions that are not intended to be shared outside of the company. They represent custom extensions that users would not expect to find in the IEC standard itself.
Footnotes
45 For these examples all the new classes will be prefixed with Ext to make it easier to differentiate what is an extension and what is from the CIM. This is not a requirement of extensions although some tools would have issues with two classes having the same name, even if contained within different packages.
Introducing New Application Areas – CIM for Gas
Another scenario requiring extensions is when a new application area must be modeled with extensions built on the existing CIM concepts and structure that would be of relevance to other utilities. In this situation the extensions are done both to model the data requirements of the utility or project, but with the intention of eventually proposing them to the IEC working groups as an extension to the CIM that would be added to a later revision.
This example will use the scenario of a utility wishing to extend the CIM to model the gas network so that they can better integrate control and monitoring of the two networks. This will involve the modeling of the gas network itself and tying it into the existing CIM classes covering the electrical network where the two are interconnected (that is, at a gas-fired power station).
Adding New Classes
The CIM’s existing Equipment class is taken as the starting point and where, for electrical conduction, it is specialized into ConductingEquipment, for the gas network a complimentary class ExtGasTransferEquipment is created to represent any equipment that can transfer gas.
This ExtGasTransferEquipment class is then sub-classed into:
ExtGasPipe, with attributes to define its diameter and pressureExtGasometerto represent a point of gas storage with an attribute to define its capacityExtGasSupplyPointto define a point on the network where gas is supplied
Refining Existing Classes
For this example, a class that defines information about the gas being supplied will be added. The CIM already contains a FossilFuel class that is tied to ThermalGeneratingUnit and so this class will be extended to define natural gas with the ExtNaturalGas class as shown in Figure 10-4.
This re-uses an existing CIM class and extends it with the additional data that is needed for modeling the gas network, in this case the calorific value of the gas. By specializing the existing CIM class it inherits an association to the existing CIM ThermalGeneratingUnit class. Recall that specialization is a type of association between classes where the specialized class (also known as subclass) inherits all of the attributes and associations of the parent, but allows additional, specific attributes for the subclass to be added.
Assigning a Gas Supply Point
As part of this extension the connection points between the gas and electrical networks at a gas-fired power station will be explicitly modeled. In Figure 10-3 the ExtGasSupplyPoint class was added and so now add an association between this and the existing CIM classes that represent electrical generators, primarily the ThermalGeneratingUnit class.
ThermalGeneratingUnit however can refer to any power station that converts heat to electricity, whether it is fuelled by coal, gas, oil, or nuclear. As such the existing class can be refined and specialized into ExtGasFiredGeneratingUnit that has an association to the ExtGasSupplyPoint as shown in Figure 10-5. The ExtGasTransferEquipment class has an association added to the ExtNaturalGas class, which is then inherited by all subclasses of ExtGasTransferEquipment, including ExtGasSupplyPoint.
Gas Containment
The existing CIM containment structure has Geographical Regions and Sub-Geographical Regions containing Substations. This is suitable for this gas network example, but gas pipes and gasometers are not within VoltageLevels so an equivalent containment for gas is required.
A ExtGasPressureLevel class is analogous to VoltageLevel and will be used to contain gas equipment. This will still reside inside a Substation so the existing Substation class must be extended to include an aggregation association between it and the new ExtGasPressureLevel class to mirror the Substation-VoltageLevel relationship.
To add this new aggregation association to Substation an extension class, ExtSubstation is added which Substation now inherits from (as well as its standard inheritance from EquipmentContainer) as shown in Figure 10-6. When using this construct in a contextual model the ExtGasPressureLevel would have a restriction placed on the aggregation association it inherits from EquipmentContainer so that it may only contain instances of Equipment that are subclasses of ExtGasTransferEquipment. The alternative would be to have an explicit association between ExtGasPressureLevel and ExtGasTransferEquipment which may be considered more appropriate but for this example the existing CIM containment structure will be re-used.
Gas Extensions Summary
The CIM UML has now been extended with:
- Attributes and classes to record information about legacy data sources
- Refinement of existing CIM classes for fossil fuels and generating units
- A new hierarchy of classes for modeling a gas network
- Extended the CIM containment classes to provide a parallel gas containment structure
All the extensions to existing CIM classes have been accomplished using inheritance and no attributes or associations have been added to the existing CIM classes. All the extensions can be identified so systems implementing this extended model can still export standard CIM by discarded extended data (or converting it to a standard representation in the case of refined classes – that is, by exporting a ExtGasFiredGeneratingUnit as a ThermalGeneratingUnit and ignoring any attributes/associations introduced in the ExtGasFiredGeneratingUnit class).
Internal vs. Global Extensions
All the extensions that have been introduced are shown in Figure 10-7. The extensions to Equipment to add the fromABCSystem flag and the ExtOriginalSource class can be considered internal extensions that are not of interest to other utilities not directly involved in the project and so are internal extensions. The other extensions, to add the gas network, could be considered global extensions that would be of interest to other utilities that also operate gas networks.
These extensions may be considered candidates for addition to the IEC standard and so may be proposed to the working groups as an addition to the CIM UML. This would mean that in the future a utility would not be requesting support for a custom, internal data model from a vendor but would instead be asking for a standards-compliant interface.
The result would be that, as shown in Figure 10-8, the standard now includes all of the gas network classes and the only extensions that need to be maintained are for the legacy data. The gas network classes have been merged into the standard and so reducing the complexity, time and cost to the utility (and their vendors) in maintaining a custom data model.
Adding a New Enumeration Through Class Extensions
In order to handle CIM for gas, the CIM UML underwent significant extensions, introducing elements for legacy data, refining existing classes, and incorporating a gas network hierarchy. The relevance of these extensions, particularly those with a global impact, is emphasized. Now, the focus shifts to the integration of custom extensions into the CIM UML, specifically through the creation of new enumerations using class extensions. This segment explores the practical aspects of handling enumerations and code lists, crucial for refining and extending CIM UML models. The goal is to provide insights into the integration of these custom elements, aligning with potential future standardization efforts.
Enumerations
An enumeration, as briefly described in Section 5, is a datatype that represents a finite set of values. Enumerations are generally used to model domains in which the values are limited and known beforehand. For instance, the type of a windfarm could be either onshore or offshore. Therefore, it is possible to have an enumeration with two values for onshore and offshore. This enumeration already exists in the 61970 package.
In the example below the WindGeneratingUnit class is extended to accommodate a new enumeration for the turbine disposition which can be either horizontal or vertical axis. The first step is to introduce the extended enumeration class into the model. In the example below, it corresponds to turbineDispositionKind which contains the two values for horizontalAxis and verticalAxis. A good practice to help distinguish the extended enumerations, classes and attributes is to use stereotypes. In the example below, Primer is used as a stereotype.
After creating the Primer stereotype, the WindGeneratingUnit class needs to be extended. To do that, this class must inherit from a new ExtWindGeneratingUnit class. The extended class contains an attribute which is linked to the pre-existing enumeration turbineDispositionKind.
Handling of code lists
The next area of focus in the enumeration space is the concept of code lists. A code list is just an enumeration defined at a profile level in which its values are assigned to a determined initial value (e.g. A01, A02, etc.). This approach gives a lot of flexibility because it allows the user to create or extend enumerations without having to modify the information model. As an example, ENTSO-E intensively uses code list for the ESMP (European Style Market Profile; IEC 62325-351).
For a practical example, let’s look at a use case that was recently handled by ENTSO-E. A process can be run in different timeframes like day-ahead or intraday for instance. In order to handle timeframes, the EnergyMarket class was recently introduced in the ESMP. In the snapshot below, reader can see how the EnergyMarket is currently modelled in the information model.
However, the timeframe attribute in EnergyMarket class is just a free string rather than an enumeration. As a result, it is necessary to do a restriction at the profile level. The first step shall be to create a new enumeration at the profile level with all the values that a determined business process requires. In the example below, it corresponds with the TimeframeTypeList enumeration. This enumeration is the same as the one described above; however, the only difference is the initial value. In the initial value, the user can define their preferred code. This enumeration needs to be based on the String datatype.
The second step shall be to create a datatype at the profile level. In the example below, it corresponds with the Timeframe_String datatype. Because the timeframe attribute in the information model level is a string, the datatype in the profile also needs to be based on a string, otherwise the dependency between profile and information model is broken. Therefore, an is-based-on association is required from the profile datatype to the one in the information model. This profile datatype shall have an attribute which points to the enumeration which was previously defined.
The final step is to bring the class into the profile, in this case the EnergyMarket class. Once profiled, the timeframe attribute datatype which is a string and comes from the information model is replaced by the Timeframe_String datatype attribute defined in a profile level.
ENTSO-E currently serializes all the code list enumerations in the ESMP CIM Package XSD46 and the plan is also to move to new formats like JSON schema or Apache Avro in near future. This approach is also quite flexible because it allows the user to validate any of the XSD profiles against the XSD codelist. Serialization is currently done using CIMContextor and CIMSyntaxGen which are Enterprise Architect add-ins published under Apache 2 license. At this time, there is no support in CIMTool or Schema Composer for this style of profile generation.
ENTSO-E frequently publishes new versions of their code list in their webpage . More detailed information on the ESMP profiling process and handling of code list can be found there.
Footnotes
46https://www.entsoe.eu/publications/electronic-data-interchange-edi-library/
Case Study
Jeff Kimble has learned that although the CIM is fairly mature, there are always new use cases being developed that can cause gaps between the current state of the CIM and what is needed for integration. The causes of these gaps are typically new technology and capabilities that require new attributes or classes to be added. Sometimes gaps are caused by a need to integrate two or more legacy systems, sometimes caused when utilities merge. Another source of model extensions is when CIM-like methods are applied to other domains, for example, water, or gas utilities (because the CIM is an electrical system model). Lastly, Jeff has learned that his organization can always externalize enumerations into their own profiles so that their stricter data requirements are still compatible with the canonical CIM.
By using a process to identify where extensions have been added to the model Jeff realizes that when updates are made to the CIM it will be easier to migrate those updates to artifacts that have been used for integration (assuming there is a business case for doing so). Since Electric Innovation Utility is considering acquiring a gas utility, Jeff finds these gas examples very well suited for the type of extensions he envisions for his organization’s enterprise semantic model.
Some reasons for extending the CIM include
A
Support for legacy systems
B
Support for capturing extensions that need to be shared with the IEC and Working Groups
C
Support for other domains, that is, water, gas
D
All of the above
A. Support for legacy systems
Using an identifier as a prefix or suffix to an extension
A
Allows the appropriate titles to be used with the extension
B
Makes the extension required for the standard
C
Facilitates identifying where extensions exist to avoid conflict with the standard
D
Makes it harder to identify where an extension has occurred
C. Facilitates identifying where extensions exist to avoid conflict with the standard
To identify an extension
A
Ext must be used
B
Zee must be used
C
XYZ must be used
D
Any suffix or prefix could be used as long as it is used consistently
D. Any suffix or prefix could be used as long as it is used consistently
A utility wants to extend the CIM to support water operations. To extend the equipment class to support water, one class that might be added is…
A
ExtGasEquipment
B
Equipment
C
ExtWaterEquipment
D
ExtElectricalEquipment
C. ExtWaterEquipment
A specialized class is a class that…
A
Inherits all of the attributes and associations of the parent class
B
Feels really good about itself
C
Does not inherit any attributes from the parent because it is special
D
Inherits some attributes, but ignores some other
A. Inherits all of the attributes and associations of the parent class
What is the added value of using code lists
A
Define multiple codes for an enumeration value
B
Combining different enumerations with codes.
C
Flexibility as it allows to create new enumerations and values without updating the canonical CIM
D
No value at all
C. Flexibility as it allows to create new enumerations and values without updating the canonical CIM