Use Cases for Multi-utility CIM extensions
This document describes use-cases that could benefit from an extensionof the Common Information Model (CIM). These use-cases document business processes that apply to both the electricity infrastructure and other infrastructures in similar fashion (e.g. gas). Application of CIM compliant support systems in these processes is complicated as the CIM does not support the other infrastructures.
It is not difficult to find use-cases for processes that include more than just the electricity distribution grid. Most utility processes in Western Europe do not make a distinction between the gas and power infrastructure. The distribution grid that the utility is responsible for are monitored and controlled from a single (EMS, DMS, SCADA) system. The same is true for geographic location (GIS), asset management, customer management (CMS, CRM, SAP), maintenance (e.g. SAP-PM) and most other processes. Software functions may have specific features to support different networks (load flow, forecast) but on a systems level the support tools cover far more than just the power grid. The focus on electricity (only) in the CIM may, from the perspective of the European utility, seem almost artificial.
The main use-case covers the revision of infrastructures and stems from the DURF (Digital exchange of revision data in Dutch) project. The project aims to standardise the exchange of data that is needed for the creation, modification and removal of infrastructure components between utilities and contractors/surveyors. Most infrastructures (power, gas, telecom, water, sewage, TV-cable) in the Netherlands are underground. Maintenance of these infrastructures is combined for all affected networks for efficiency reasons. See the process below.
The utility designs new (or changes to existing) infrastructure components. The design is published (RFP) and contractors (AanNemer) make offers. After realisation and localisation (InMeten) the as-build data for (part of) the work is send to the utility with references to the design. The data contains large amounts of administrative data (type of cable, manufacturing date, shielding, joints used, etc.) along with connectivity and geography. This data should (ideally) go from and back into the utility systems without manual interventions.
A second, and similar, use-case covers newnetwork connections. Grid extensions (for new neighbourhoods or commercial sites for instance) cause data exchanges between various market parties and utilities. In most cases the new connections include more than just the power grid. The utility, in increasing amount of cases, also creates a telecom infrastructure along with the energy distribution networks for future use in smart grid and demand response applications. The telecom network is regarded to be assets by the utility just like the power and gas network. The data on these connections is added to the GIS, SCADA, CRM and other utility systems for all network types in the project. For this use-case utilities require a single method for the identification and localisation of assets. It would be inconvenient (at least) to use different ways to model connectivity and geography for different networks within the same project. The CIM methods to explicitly define connectivity for instance would work just fine for gas and other infrastructures.
The third and final use-case in support of the extension of the CIM for use for other (than power) grid is related to the European INSPIRE directive (Infrastructure for Spatial Information in the European Community; see: INSPIRE require spatial data on utility & governmental services in a specific format. The INSPIRE initiative causes European institutions and governments to follow the same rules and regulations. Reporting in INSPIRE style requires a uniform approach to localisation for all infrastructures. Financial reporting shows similar developments.
Request
We ask the IEC/TC57 Working Groups that are responsible for the development and maintenance of the CIM to change the CIM in ways that is usable for other infrastructures. This may require two distinct changes:
-Make the current model packages more general to make them applicable for other networks, less dependent on power-specific model components and provide methods to add additional packages to the current model.
-Enable the extension of the existing packages with gas (or water, telecom, sewage, TV cable) specific classes though hooks & guidelines.
We feel that this development further strengthens the position of the CIM and help to make a transition to a CIM ontology.