CIM-MultiSpeak Harmonization: Practical Guidance for System Integration

Transcription

1 CIM-MultiSpeak Harmonization: Practical Guidance for Integration Dr. Gerald R. Gray Electric Power Research Institute (EPRI) 942 Corridor Park Blvd, Knoxville, TN 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 investorowned 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 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, [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 1 UML is a specification defining a graphical language for visualizing, specifying, constructing, and documenting the artifacts of distributed object systems [3] methodology was developed for creating MultiSpeak equivalents of IEC 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 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 This update to the report details the mappings of all 23 of the IEC st 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 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

2 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 st 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). CustomerMeterDataSet N/A 2 EndDeviceAssets EndDeviceControls EndDeviceEvents EndDeviceFirmware MeterAssetConfig MeterAssetReading MeterReadings Figure 2-1 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 [7] that will be published in January 2013 for those details. CIM Profile Mapping Legend MeterReadSchedule MeterServiceRequests MeterEvents PricingStructureConfig ReceiptRecord SDPLocationConfig ServiceCategoryConfig ServiceDeliveryPointConfig All key identifiers map, most attributes map Some key identifiers map, many missing attributes Significant gaps in the mapping ServiceLocationConfig SupplierConfig TransactionRecord Table 2-1 CIM profile to MultiSpeak Correlation Level Profile Name Correlation Level AuxiliaryAgreementConfig CustomerAccountConfig 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 (CIS) or from a CIS to an externally entity see less support, where interactions CustomerAgreementConfig CustomerConfig 2 CustomerMeterDataSet is a composition of several profiles; CustomerAgreement, EndDeviceAsset, SDPLocation, ServiceCategory, ServicedeliveryPoint, and ServiceLocation. The reader is referred to the EPRI report [7] for the specifics of those mappings.

3 between systems such as a CIS and a metering system have much higher degrees of correlation 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 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 1 st 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 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 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.

4 MultiSpeak mspobject objectid replaceid utility errorstring verb any CIM IdentifiedObject mrid aliasname description localname pathname name Common Organisation Figure 2-2 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 st 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 (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 [4] there is defined guidance for using CIM profiles with both Java Messaging Service (JMS) as well as SOAP. name 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, 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. A A CIM Interface ESB MultiSpeak Interface B C D B Figure 3-1 Abstract system mapping from CIM to MultiSpeak via an ESB This was demonstrated in a proof concept test of the On Demand Meter Reading use case. This use case presumes that rather than pick up a meter reading per its normal schedule, a customer service representative might initiate an On Demand Meter Read if there has been a complaint of an inaccurate bill or this might also be used to determine if power has been restored to a meter (sometimes referred to as a meter ping). In MultiSpeak the InitiateMeterReadings web service can be used for this meter ping action. Once the meter responds the results are normally returned via a ReadingChangedNotification service. However, by mapping the messages in an ESB, the InitiateMeterReadings service can instead call the CIM GetMeterReadings service (as defined in IEC ). When the meter reading is returned it is mapped back to the MultiSpeak ReadingChangedNotification in the ESB. Table 3-1 Key message headers attributes of CIM and MultiSpeak; adapted from EPRI report [6] MultiSpeak attribute CIM attribute Comments

5 N/A - verb is included in the operation naming. N/A - noun is included as part of operation naming. MajorVersion MinorVersion Build Branch BuildString AppSource AppVersion Company MessageID Verb Noun Revision Source ReplayDetection (Nonce, Created) Identifies the action to be taken Identifies the type of payload The MultiSpeak integer type version attributes need to be changed to string; the resulting attributes then concatenated and mapped to Revision Identifying the source of the message, which should be the ID of the system or organization; for MultiSpeak the AppSource, AppVersion and Company may be concatenated and mapped to this field A complextype made up of Nonce (a GUID or random number good for at least a day) and Created, a timestamp. Timestamp Timestamp A timestamp generated by the source system to indicate when the message was created. transactionid - is not included in the message header. It is included in the operation definition for those operations for which it is required. CorrelationID Supplied on a request, so the client can match a corresponding reply message. The server will use the incoming correlation ID on the outgoing reply. responseurl ReplyAddress responseurl is not part of the MultiSpeakMsg Header, but part of the payload, but can be mapped to ReplyAddress Context Context Indicates the message pattern, e.g. Request, Response For the full table of message header mappings see the updated EPRI CIM-MultiSpeak harmonization report. [7] A InitiateMeterReadings ReadingChangedNotification ESB GetMeterReadings B Figure 3-2 Example service mapping for an On Demand Meter Read using both MultiSpeak and CIM services 4. FUTURE RESEARCH: TURNABOUT IS FAIR PLAY The CIM and MultiSpeak harmonization work has focused first on mapping from CIM to MultiSpeak at the profile (subset of the entire model) level as well as demonstrating the ability to integrate in a web service environment via an ESB. However, if one was to go from MultiSpeak to CIM it is not as simple as simply reversing the mapping for a few reasons, although for those profiles that have a high degree of correlation this may be possible. This is because just as there are classes, attributes, and relationships that are fairly mature in CIM that do not exist in MultiSpeak, there are also places in MultiSpeak that are very mature that do not have equivalents in the CIM yet. While identifiers map very well such as the mrid to objectid and some attributes have one-to-one mapping, others places aren t as clean. Gaps obviously will still be gaps. The other challenge will be in transformations. In some places in the CIM multiple string attributes were concatenated together and mapped to a single MultiSpeak attribute. To reverse this operation the MultiSpeak string that is passed would have to be substringed and a scheme developed whereby this could be accomplished in a

6 consistent fashion. When concatenating from CIM to MultiSpeak a delimiter can be added but there is no guarantee such a delimited would exist should the transaction be reversed. 5. MOVING TO THE INTERNATIONAL DOMAIN IEC TC57 recently approved a New Work in Progress (NWIP) proposal which will become IEC Technical Report (TR) The EPRI CIM-MultiSpeak Harmonization report will be contributed to this international work. This TR will also include mappings for IEC nd Edition to the current release of MultiSpeak (estimated to be v5). (This effort needs a few more technical experts to be named from participating countries before work can begin). This effort will move the harmonization from a good suggestion to an internally recognized best practice. 6. OUTCOMES One of the key outcomes of this effort was an understanding the best practices of the respective standards, for example, the CIM uses generic classes that can be reused throughout the model for routine things such as status or event, which can then be generalized into specific classes to meet the needs of a specific context, i.e. document status. MultiSpeak uses a good practice of using a class to hold as a list in the event that there might be multiple types of an entity, for example, in the CIM primary address and secondary address is used, in MultiSpeak any number of addresses can be used with the ability to prioritize which address has precedence which makes the model fairly flexible. Figure 6-1 Example of how MultiSpeak flexibly handles multiple instances of contact information and its priority for use Looking at the CIM first edition profiles, the address is limited to primary address and secondary address. Nominally this might be all that one would require, however the MultiSpeak structure offers inherent flexibility if more addresses (street, , phone, other) should they be needed without requiring the integrator to go to great effort to refactor either the model or the code for the integration. 7. SUMMARY Frequently as part of this effort question are posed as to whether this work will lead to unification of the two standards. Often there is confusion on what harmonization means. To be clear, there is no expectation of convergence of the two standards any time soon, and in fact, this may never occur as each standard continues to serve the needs of its respective constituents. However, over time, as each respective standards body works to encompass key standard use cases, and shares best practices with the other, identifying and eliminating gaps, the distance to integrate applications using either standard should be reduced and harmonization level increased. Unification of the two standards may occur someday but it will not be within the next release cycle of either standard. Future work will include mapping of the projected release 5 of MultiSpeak with the IEC nd edition profiles and this work will also be incorporated into the IEC document. It should be noted that IEC nd edition will likely be published in Q Work will immediately begin on 3 rd edition use cases that are being defined at this time. Finding from the harmonization work will continue to be contributed and vetted in the respective standards bodies for consideration in future releases. 8. REFERENCES 1. MultiSpeak, 2. International Electrotechnical Commission, 3. Unified Modeling Language, Retrieved: ng_spec_catalog.htm#uml, Object Modeling Group 4. IEC , Implementation profiles for IEC 61968, 5. IEC Meter Reading and Control, m_pk/ Gray, G. (2011). CIM-MultiSpeak Harmonization, , Final Report, November Gray, G. (2012). CIM-MultiSpeak Harmonization, 2 nd Edition, , Final Report, November 2012.

7 Biography Gerald R. Gray is an Enterprise Architect and Senior Project Manager focusing on Enterprise Architecture & Integration research at the Electric Power Research Institute (EPRI). Dr. Gray participates in the development of numerous industry standards as a member of IEC TC57 and MultiSpeak, currently the technical editor of IEC CIM-MultiSpeak Harmonization. He has also been a contributing author to OpenAMI-ENT, OpenADE, OpenADR, and OpenHAN within the UCAIUG OpenSG user group, as well as contributing to the development of the OASIS Energy Market Information Exchange (EMIX) and Energy-Interop committee specifications. He is currently the chair of OpenSG s SG-Enterprise Task Force. Dr. Gray has a BS in Management/Computer Information s from Park University, a Masters of Administrative Sciences in Managing Information s from the University of Montana and a Doctor of Philosophy in Organization and Management with a specialization in Information Technology from Capella University.