Learning Objectives
- Understand the key words used and the relationship between Verb/Noun pairs
- Gain familiarity with some of the standard integration patterns
- Understand where to go to get more information on using the CIM for application integration
Introduction
One of the early criticisms of the CIM was that although it was a large, comprehensive model, users found very limited guidance on using it to integrate systems. The learning curve associated with CIM was steep. Even after profiles were introduced, it was difficult for practitioners to go from understanding the internals of a profile to applying it to the integration of two systems. CIM is intended to be used as a reference; it is not a guide. By comparison, a reader can find the meaning of words in a reference dictionary, but there is no guidance on how to write a sentence.
For these reasons the Working Group that supports CIM for distribution (IEC 61968) where application integration is a significant concern, took on the task of creating guidance for the use of the CIM in systems integration. This built on early developments made by the user community in forums such as the CIM Users Group and the Utility Communication Architecture International Users Group (UCAIUG). This sharing of information reflects the importance of the relationship between standards development organizations (SDO) and the supporting users groups that put standards into practice. The SDO, by producing a standard says in so many words, “thou shalt…” and the user community, as they attempt to put the standard into practice, finding gaps and creating extensions, feed their findings back to the SDO, in effect stating, “yes, and…”
To this end Working Group 14 created Implementation Profiles as a standard (see IEC 61968-100: Application integration at electric utilities – System interfaces for distribution management – Part 100: Implementation Profiles). This standard provides guidance on how to use IEC 61968 for utility application integration, specifically for Parts 3 through 9. The creation of profiles was already covered in previous sections, so this section will focus on the integration patterns and the naming convention for services.
The focus of IEC 61968-100 is web services and java messaging services (JMS), however, other integration technologies could be used, that is, Extensible Messaging and Presence Protocol (XMPP) or Representational State Transfer (REST). In fact, technologies such as XMPP and REST have been used with CIM profiles, it just so happens that the scope of the specification was limited to web services and JMS at the time of its writing.
Verbs
First it is important to understand the use of verbs and nouns in the service naming convention described by IEC 61968-100. Once the use of verbs and nouns in the naming convention is covered some of the basic integration patterns such as request/response will be explored.
For JSON/REST
The 61968-100 standard was written specifically for the use of SOAP web services or JMS and as such makes no use of HTTP Verbs. If you're planning on doing a REST implementation, please see Section 13.
Table 11-1: CIM Verbs in IEC 61968-100:2013 and their usage in naming patterns
| Request Verb | Reply Verb | Event Verb | Usage |
|---|---|---|---|
| Get | Reply | (None) | Query |
| Create | Reply | Created | Transaction |
| Change | Reply | Changed | Transaction |
| Cancel | Reply | Canceled | Transaction |
| Close | Reply | Closed | Transaction |
| Delete | Reply | Deleted | Transaction |
| Execute | Reply | Executed | Transaction |
First it is important to be familiar with the list of verbs and when they are used.
Get – is used for queries.Create – is used when creating an object that match the noun (more on this in a moment).Delete – is used to destroy an object although an object in a business system might only be marked for deletion (keeping the record of the activity).Close and Cancel – are used in relation to a business process such as closing a work order or perhaps canceling a request.Change – is used to modify an object that was used in previously, for example, as part of a Create or Created action.Execute – this is used in complex transactions and is used with an OperationSet, that is, a structure that may hold actions and contain more than one verb. This section will be limited to some simple patterns so OperationSet will not be explored here.
In the second edition of IEC 61968-100, close has been removed. Also a new verb was added to the list:
Update – used to make a partial modification of an existing object without having to fill out every piece of information like a change command.
Nouns
In IEC 61968-100, the use of nouns is used to convey or identify a payload structure. This often is equivalent to a profile, something that has been covered in prior section. A message payload is typically conveyed using an XML document that conforms to an XML schema, and can be validated against an XSD. For example, a standard profile from IEC 61968-9 is an EndDeviceEvent profile. This profile is used to pass information about events that occur in the distribution network to other systems that may be interested. For example, if a smart meter sends a “last gasp” (the last message before it loses power) when this message is received by the Advanced Metering Infrastructure (AMI) Head-End System (HES), it might pass this information on to a Meter Data Management System (MDMS) or an Outage Management System (OMS) using an EndDeviceEvent message profile. But first, an understanding of some basic integration patterns will be in order.
Integration Patterns
The simplest and fairly common integration pattern is the request/response pattern. One system makes a request of another, and that system responds. In this generic pattern shown in Figure 11-1, the client makes a request of the server, and the server responds. The request is represented as the verb(noun) shown on the top arrow.
Figure 11-1: Basic request/response pattern
This basic pattern could be applied to the AMI HES to OMS integration that was described earlier. If the AMI HES wants to send an EndDeviceEvent message it will need to create the EndDeviceEvent object, so the basic message pattern looks like Figure 11-2.
Figure 11-2: Basic request/response pattern using the Create verb and the EndDeviceEvent object
In this example the Create verb is used in conjunction with the EndDeviceEvent noun. Together this makes up the naming pattern of the web service. Once the OMS receives this message it responds with the Reply, to let the AMI HES know that it has received the EndDeviceEvent.48
For developers, as they begin to get comfortable with the naming convention they very quickly begin to understand the types of interactions that are occurring, and the types of events and messaging that is being supported. Now to move onto a slightly more complex example, suppose that a remote disconnect is going to be processed for a customer. There are several steps that will need to occur:
- The CIS will need to pass a command to the AMI HES to initiate the disconnect (in this case via a MDMS).
- The disconnect will be performed and the notice of the event will be passed back to the CIS.
- A meter reading will be initiated to get the final read from the meter and pass this back to the CIS for billing purposes.
The sequence diagram to capture the follow and naming of the messages is shown in Figure 11-3.
Figure 11-3: Example of message integration required for a remote disconnect of a smart meter
As can be seen, the series of messages begins with a Create which uses an EndDeviceControls object. This is an object that is used for sending commands to end devices. Meters are considered “end devices” in the CIM. Rather than specify every type of possible end device with messages specific to each, the generic EndDeviceControls was created to handle commands to all the different types of devices.
The “create” is passed from the MDMS to the AMI HES. In turn each system responds with a Reply message so that the sending system knows that the message was received. When the remote disconnect is performed at the meter this will generate an EndDeviceEvent. This message is passed back up to the calling systems using the Created verb (as this is an event based on a prior action, the –ED is appended to the Create).
Finally, the MDMS initiates a meter reading to get the values from the smart meter post disconnect. This uses a Get with a noun of MeterReadings. The Reply returns the meter readings to the MDMS, which in turn, again, post event, uses Created to pass the meter readings to the CIS for billing.
At first glance this may appear to be confusing, but as developers become familiar with the patterns and the message profiles that are used, it soon becomes second nature. The added benefit is that developer A and developer B and developer N have not all come up with different naming conventions and patterns for the integration. It is this predictable pattern that allows developers to come up to speed very quickly on how to do system integration based on IEC 61968-100 guidance.
Only some basic integration patterns were used in this section to highlight the use of Verb/Noun pairing. IEC 61968-100 goes into more detail on the types of integration patterns, how to structure messages, error handling, use with JMS, and how to handle topics such as version control. This is out of scope for this section, but the reader is invited to explore this specification, especially if they are interested in standards-based systems integration.
Footnotes
48 For the specifics on message headers, the contents of the XML of the messages, and the structure of error handling, see IEC 61968-100 for more information.
Integration With Part IEC 61968-100 Second Edition
Although IEC 61968-100 is largely the same as the first edition, these versions are still fundamentally different and thus are not interoperable with each other. This means that a web service that was designed using the first edition will not be able to properly communicate with one using the 2nd edition. For those upgrading their systems, this is important to keep in mind. However, there are tools out there that exist to ease the transition between the two variations of the standard. For example, there is an option in CIMTool to generate part 100 2nd edition compliant schema during the profiling process when creating profiles. There is also a GitHub link in the 2nd edition that links to a Java program that will update existing 61968-100:2013 XSD profiles to a 2nd edition version. Thus, there are options to generate 2nd edition-compliant XSDs for both new and existing profiles.
Although using the approaches outlined above will create compliant schema, it is important to go through the new standard and see what changes have been made. For example, error codes have been significantly trimmed down in part 100 and have been left to other standards to define where necessary. Many elements have slightly changed names, such as Compressed becoming CompressedPayload. A new verb has been added and an older one removed, so that could impact existing systems that relied upon the deprecated verb. Additionally, the mrid is now enforced as a UUID-type string. Any of these changes could break existing systems so it is important to be fully aware of what these tools are changing before upgrading to the second edition.
Case Study
Innovation is Electric Innovation Utility’s “middle” name, but Jeff Kimble knows that his team also has to support legacy databases and JMS message integrations. However, as the CIM University training comes to a close he feels very comfortable going back to his organization armed with this CIM knowledge. He has learned that the CIM is very robust as a reference model, with hundreds of classes and attributes that describes the utility environment. He has learned that not only can the model be used to exchange network diagrams, but that the model can be pared down to create a profile to either describe a smaller section or to even be used for messaging.
He has seen how the model can be used for bi-directional transformation, that the model can also be used to transform to and from database or other file schemas, which will help his team with its legacy integration work. Finally, he has learned that there is now specific guidance available for application integration, guidance that will replace the inconsistent naming conventions and patterns for integration using the enterprise service bus in his organization, with something that is consistent and repeatable, that supports both his legacy JMS integrations, but also his more recent integrations using web services. Finally, although his utility has recently been exploring the use of RESTful architecture and testing some XMPP protocols, the CIM profiles do not preclude using these types of integration technologies.
The primary naming convention for CIM-based integration consists of a _____ pair
A
Verb/Noun
B
Command/Noun
C
Noun/Object
D
Integration/Object
A. Verb/Noun
The object used in a normal (non-event) response is a _________.
A
Change
B
Get
C
Create
D
Reply
D. Reply
The verb used for queries is…
A
Change
B
Get
C
Create
D
Reply
B. Get
The verb used to alter an object once it has been created is…
A
Change
B
Get
C
Create
D
Reply
A. Change
A CreateEndDeviceControls was used to initiate a command to a device. Later after some processing, some additional information needs to be passed to the calling system. This will most likely use the ______ verb.
A
Get
B
Change
C
Created
D
Create
C. Created