CIM-MultiSpeak Harmonization: Practical Guidance for System Integration

Grid-Interop Forum 2012

Dr. Gerald R. Gray

Electric Power Research Institute (EPRI)
942 Corridor Park Blvd, Knoxville, TN 37932

Grid-Interop Forum 2012

Authors Last Name(s)

Keywords: Common Information Model, MultiSpeak, Integration, Standards, Harmonization

Abstract

MultiSpeak™ [1] and the International Electrotechnical Committee (IEC) Common Information Model (CIM) [2] are standards that both serve the utility application integration domain. However, the standards evolved in slightly different ways and serve two slightly different constituencies. The CIM tends to be used by large investor-owned utilities, with an underlying assumption of larger information technology staffs capable of leveraging the information model and molding it to serve their purposes. MultiSpeak tends to serve smaller utilities that have smaller IT staffs. MultiSpeak started as an interface standard and was later reengineered into the unified modeling language (UML)[1]. The CIM is represented in UML with implementation guidance being provided by the draft of 61968-100 CDV [4]. The CIM community is close to releasing a second edition of Part 9 (Meter Reading and Control) [5] while MultiSpeak is moving toward a release of 4.x.

This paper gives an update on what has occurred since the original EPRI report, 1024443 [6], which covered harmonization of CIM and MultiSpeak, Roughly 40% the CIM first edition Part 9 profiles were mapped during this initial effort. This paper will provide an update on the degree of correlation seen for the remaining CIM Part 9 profiles, and reflect on what was learned in a lab environment in integrating the respective standards using an enterprise service bus (ESB).

1.  introduction

With the publication of the initial EPRI report there were several important findings, 1) CIM and MultiSpeak both represented ontologies but the tooling available to assess or analyze the models in the entirety was limited 2) a methodology was developed for creating MultiSpeak equivalents of IEC 61968-9 profiles 3) a proof of concept mapping to satisfy the On Demand Meter Read was accomplished to demonstrate the practicality of using both CIM and MultiSpeak web services for integration, and 4) mappings of roughly 11 of the 23 IEC 61968-9 first edition profiles was completed showing the correlations, transformations, and existing gaps between the two models.

A second edition of the EPRI report will be released in 2013. This update to the report details the mappings of all 23 of the IEC 61968-9 1st edition profiles. While the specific details of the mappings are beyond the scope of this paper, this paper will provide the overall ranking of profile correlation (low, medium, high) and guidance on the use of the profiles for integration.

2.  More mappings

The initial harmonization effort completed the mappings of 11 of the 23 IEC 61968-9 profiles. The smallest profiles were mapping first, i.e. EndDeviceEvents, ServiceCategoryConfig until a methodology was perfected for developing MultiSpeak equivalents of the CIM profiles and to also have the profile development be model driven. That is, the UML would be used to generate the profile as an XSD with a goal of requiring a minimum amount of editing once it was generated. In this fashion the UML could be stored and maintained with the same UML that contained the parent reference model.

In 2012 work continued with the remaining profiles with all profile mappings to be published at the end of the year in an update to the original EPRI report as a second edition. As the profiles were created they were reviewed by MultiSpeak and CIM experts to make sure that the intent and semantics of the attributes in the CIM profile were understood. Where naming was different or underlying assumptions of the business context in MultiSpeak varied from CIM, that an accurate representation was being developed.

The profiles, as generated were also developed with an eye on integration, for example, when a transformation called for a set of strings to be concatenated or a single string to be substringed, approaching the problem from a practical “how would a systems integrator” solve this problem point of view. While any two systems integrators might solve a transformation differently, the EPRI report provides guidance so that the integration problem is solved in a consistent fashion, based on a consistent and correct interpretation of semantics.

In the IEC 61968-9 1st Edition profiles there are many attributes that are optional. The typical structure of the profile is that there is some high level collection of attributes and this is usually a 0-to-many construct. For example, in the figure below, the profile EndDeviceEvents, the schema view shows that there are 0-to-many EndDeviceEvent. Nominally, given this structure, xtensible markup language (XML) that contained nothing would validate against such an XML schema definition (XSD).

Figure 21 Example of the high level structure of a CIM profile, EndDeviceEvents that contains 0-to-many EndDeviceEvent

The 23 CIM profiles are listed in Table 2-1 with a relative correlation level assigned to each. The details of each profile mapping are beyond the scope of this paper and the reader is referred to EPRI report 1026585 [7] that will be published in January 2013 for those details.

CIM Profile Mapping Legend

High / All key identifiers map, most attributes map
Medium / Some key identifiers map, many missing attributes
Low / Significant gaps in the mapping

Table 21 CIM profile to MultiSpeak Correlation Level

Profile Name / Correlation
Level
AuxiliaryAgreementConfig / Low
CustomerAccountConfig / Medium
CustomerAgreementConfig / Low
CustomerConfig / High
CustomerMeterDataSet / N/A*[2]
EndDeviceAssets / Medium
EndDeviceControls / High
EndDeviceEvents / High
EndDeviceFirmware / High
MeterAssetConfig / Medium
MeterAssetReading / High
MeterReadings / High
MeterReadSchedule / High
MeterServiceRequests / Medium
MeterSystemEvents / High
PricingStructureConfig / Low
ReceiptRecord / Low
SDPLocationConfig / High
ServiceCategoryConfig / High
ServiceDeliveryPointConfig / High
ServiceLocationConfig / High
SupplierConfig / High
TransactionRecord / Low

Typically the situation for CIM profiles that have a low degree of correlation with MultiSpeak is that MultiSpeak evolved from an interface specification, with priority given to interfaces between systems within the utility back-office. This is why profiles that support customer agreements, auxiliary agreements, transactions, i.e. interactions with a Customer Information System (CIS) or from a CIS to an externally entity see less support, where interactions between systems such as a CIS and a metering system have much higher degrees of correlation.

2.1.1.  Using the correlation table

While specifics on the mapping from one profile to another are available in the EPRI report [7] the table can be used to give the integrator an initial sense of the level of effort that will be required for any given profile integration. The low hanging fruit for a vendor or systems integrator would be those profiles that are already supported in a vendor’s product or have a high degree of correlation. It is not to say that the other profiles can’t be mapped, they can. Even for profiles with low correlation to the CIM, the EPRI report details where the appropriate data elements exist. For profiles with a low correlation level the integrator should have an expectation that the gaps would need to be addressed via business logic and potentially non-standard MultiSpeak interfaces.

That being said, profiles with low correlation would not likely be candidates for an initial integration effort and profiles with high degrees of correlation will take significantly less effort with key identifiers and attributes mapping well.

However, for those profiles with a medium correlation level it will be important to know what the key issue is for these profiles so that the integrator is prepare to address them. Those profiles are discussed below.

CustomerAccountConfig

This is not a particularly complex profile and in fact the key identifier (ID of the customer account maps). However, there are two classes that make up roughly 50% of this profile, Status and docStatus. (docStatus is a generalization of the Status class). These two classes are not present in any of the other MultiSpeak profiles (the generic Status class is under consideration for a future version) at the time of this writing. So while it would need to be accounted for in any of the profiles, it bumps this profile down to “Medium” due to the fact that these two classes account for such a large percentage of the overall profile.

EndDeviceAssets

This profile provides some interesting challenges. It is a fairly large profile which can support quite a few attributes relating to the Communications, Connect/Disconnect function, and information both about the electric metering and other generic asset information. Each of these categories has its analog in MultiSpeak. In fact, MultiSpeak handles the communication function in a more elegant way. For communications MultiSpeak uses a moduleList as a holder for 0-to-many modules which may have their own communications function. This mirrors end devices that may have say, one module for Home Area Network (HAN) communications within the premise and a separate module for back haul communications to the utility. But by using the moduleList structure it is a very flexible way to handle this type of information when it is unknown how many modules any given end device might support. However, there are also several attributes of the CIM communication function that are missing in MultiSpeak.

Another challenge is that while both CIM and MultiSpeak support numerous attributes relating to electric metering or other generic end device functions, there are significant gaps in how these attributes map. In this profile if an integrator was going from MultiSpeak to CIM the same challenges would be present; MultiSpeak has numerous attributes relating to metering and end device function that are not present in 1st Edition Meter Reading and Control profiles.

MeterAssetConfig

MeterAssetConfig suffers from the same challenges as the EndDeviceAssets profile; identifiers map to identify an asset, but there are significant gaps in the attributes themselves that would need to be complemented or augmented in business logic to address.

MeterServiceRequests

This profile is being updated in the second edition of 61968-9 and both CIM and MultiSpeak are being updated as work order information continues to mature.

This profile presents some interesting challenges because the CIM profile contains structures for the MeterAsset and OldMeterAsset (presuming the work results in a meter exchange) while MultiSpeak uses electricMeterExchange class to specifically handle this type of work. The CIM profile has only rudimentary attributes to capture work information in the first edition while the MultiSpeak ServiceOrder class is fairly robust. This profile also has some gaps in the attributes associated with a service delivery point relating to phase, current, power, etc.

2.2.  Object Identification

In this initial harmonization effort it was discovered that both CIM and MultiSpeak have a similar way of uniquely identifying things. Both models use a high level class that contains an identifier. In the CIM the identifier is master resource ID (mRID) in MultiSpeak objectID.

Figure 22 CIM and MultiSpeak classes that contain the models’ respective identification attribute

While objectID and mRID map well, some of the other attributes do not map as well. While the harmonization to date has focused on MultiSpeak 4.x to IEC 61968-9 1st Edition, it should be noted that the various name attributes have been deprecated in the profiles in the second edition. “Names” now use a Names class that also contains relationship to NameType and NameTypeAuthority as an alternative for identifying objects with mRID. How the mappings of names will be handled in 5.x of MultiSpeak is to be determined.

The other attribute of note is utility. This is indicative of the constituency that MultiSpeak serves versus that of CIM. A utility identifier in the highest order class is useful because in the constituents of MultiSpeak it is more common for one system to serve multiple utilities. For example, a single Outage Management System (OMS) might serve multiple cooperatives. It is useful to have this identifier at the highest level so that it is easy to associate data with the utility that owns or is the steward of it. For the constituents of the CIM, sharing an application is less likely as CIM users tend to be larger utilities with ample IT staffs. However, the utility can be identified, but the Organisation class with an inherited name attribute would have to be utilized to have an equivalency with the MultiSpeak utility attribute.

3.  Message Header Mapping

In addition to being able to map profiles for model alignment and messaging, it is also important to be able to integrate CIM and MultiSpeak services. While mapping the models gives the practitioner guidance on how various classes and attributes match up, in a web services environment it is also important to understand how the message header aligns.

MultiSpeak supports web services and the service calls are available in Simple Object Access Protocol (SOAP) 1.1 protocols [1].With the release of IEC 61968-100 [4] there is defined guidance for using CIM profiles with both Java Messaging Service (JMS) as well as SOAP.

While one way to solve the CIM-MultiSpeak integration problem would be to create CIM or MultiSpeak adapters (Which certainly could be done using the harmonization mappings) and use the adapter within a given application. If the organization does not have an enterprise service bus (ESB) available this may be the only viable option. However, if the organization utilizes an ESB the messages can be transformed in the ESB and in this fashion an application that only speaks MultiSpeak may remain blissfully unaware that the application that it is interfaced only speaks CIM. The reasons for utilizing an ESB are just as applicable in the CIM-MultiSpeak scenario. Once an interface is transformed it can be leveraged by any other application and could also be combined with other service as part of an orchestration to deliver new capability. For this to occur the message headers have to map in addition to the message profiles. This will be needed for service correlation as well as error mapping. If for example, System B throws an error at point D in the figure below, the error also needs to be transformed and correlated with the calling service back at point A.