By Gary A. McNaughton, Cornice Engineering Inc., and Robert Saint, National Rural Electric Cooperative Association
Over the years, many different approaches have aimed to ease the interoperation of applications. The first approach was data integration, which ensured that data stored in different programs was consistent, but otherwise each program handled business processes using its own logic. Typically this occurred using off-line batch file transfers, or occasionally using a single, common database. The next wave was application integration, where two programs exchanged data or services. In this approach, programs expose data to be shared or services that they will offer to another, usually via a point-to-point application programming interface (API). Both data and application integration can be thought of as examples of tactical approaches to solving IT problems. Both approaches still have value today, and the development of extensible markup language (XML) and web services make such tactical integration easier than it was in the days of common, but often proprietary, APIs.
The most recent concept is for all programs in an enterprise to share a common data model and, ideally, a common services bus. Enterprise integration goes beyond the capabilities of point-to-point application interfaces, but requires a strategic approach to integration. It can be difficult, expensive and time-consuming to achieve.
Service-Oriented Architecture: Enterprise Architecture Fulfilled
The concept of a service-oriented architecture (SOA) has been around for decades. With an SOA, programs provide services for use by other programs in a structured and well-documented manner. The intention is to achieve interoperability and share common IT services such as security, reliable messaging and transaction management across the entire enterprise, but to do so in a way that abstracts the details of each program’s implementation. In the past, SOA was often implemented using proprietary APIs, middleware platforms, or Common Object Request Broker Architecture (CORBA) brokers. None of these approaches became widespread because of the difficulty and cost of deploying such solutions.
SOA is only now becoming accessible with the wide availability of XML and web services programming tools. XML successfully abstracts the details of implementation of data representations, regardless of the application programming language, platform or database used. Web services have been widely used in a variety of IT environments to expose program functionality or data in the form of abstract, but well-documented, services–exactly what is needed to implement the structure of an SOA. What is needed to complete the picture, in addition to these infrastructure standards, are an enterprise-wide semantic agreement on the data objects to be exchanged (often called a data model) and a clear definition of the services to be made available on the bus, which can be used to implement utility business processes. These two remaining requirements are satisfied by the use of the MultiSpeak specification.
MultiSpeak’s Role in Integration
MultiSpeak is an open standard for software integration used in distribution utilities and all portions of vertically integrated utilities except for generation, power marketing and transmission modeling. MultiSpeak includes a common data model that is documented in the form of an XML schema and an extensive set of web services to support common utility business processes.
In addition to a comprehensive data model and set of service definitions, MultiSpeak offers an independent interoperability testing laboratory. Utilities and vendors can use this testing service to ensure that interfaces actually meet the requirements of the specification. As a result, a utility typically can integrate pairs of vendor products that have been interoperability tested without the need for further customization.
The MultiSpeak Initiative, an open collaboration of the National Rural Electric Cooperative Association and more than 40 electric utility software vendors, has developed and maintains the MultiSpeak specification. MultiSpeak interfaces are in use at more than 200 utilities, including electric cooperatives, municipals and investor-owned utilities.
Some questions a utility should ask when considering MultiSpeak as a foundation for integration are:
- Is it scalable?
- Should the integration be point-to-point or SOA-based?
- Should MultiSpeak be used for a tactical or a strategic implementation?
- Is MultiSpeak extensible?
Scalability is an issue of implementation, not a function of the underlying data model used. Two issues factor into an implementation’s scalability: protocol design and choice of messaging paradigm. First, careful thought has been given during MultiSpeak protocol design to ensure that large volumes of data can be handled efficiently. Many utility implementations have proved that the resulting protocol addresses scalability concerns. In terms of messaging, MultiSpeak web services have the same capability to be scaled as any web services implementation. Should a utility decide that a web services application is not appropriate for their particular situation, MultiSpeak can also be applied using an optional messaging framework over any message-oriented middleware platform.
Point-to-Point Integration vs. Service Bus Integration
MultiSpeak is ideally suited to supporting either a tactical approach or a strategic, SOA-based integration architecture. Figure 1 illustrates the coverage of the MultiSpeak specification when applied tactically. When used in this manner, MultiSpeak can be visualized as a set of point-to-point interfaces. Each box in Figure 1 (page 47) is an abstract software capability and each line is a supported interface between software functions. For instance, an advanced metering infrastructure (AMI) system’s capability to detect customer outages is supported in MultiSpeak using the outage detection (OD) function. An interactive voice response (IVR) system’s capability to exchange information about outages from customer phone calls is supported by this same software function, since an outage management system (OMS) needs the same data to handle the outage, regardless of the source of the detected outage.
However, once an application exposes a web service, that service is available to any other program on the utility network–thus it really creates a service bus. Figure 2 illustrates the resulting service bus architecture. When implemented in this manner, MultiSpeak can support a strategic SOA-based implementation.
An example helps clarify this relationship: Figure 3 (page 50) shows the data flows that would occur among an OMS (the outage analysis or OA function), an AMI system set up to detect outages (the OD function), an IVR used to collect outage information from customer calls (a second instance of the OD function), an IVR acting to handle customer calls and confirm restoration (the call handling or CH function) and a supervisory control and data acquisition (SCADA) system (the SCADA function) that can send device status changes to the OMS to confirm feeder outages. The data flows for the same applications are summarized for the bus architecture in Figure 4 (page 51).
This figure illustrates a key point about the specification’s bus character: once a consistent set of services is exposed by an application, reuse of services is possible. Another advantage of this structure is that the availability of granular services enables developers to flexibly and quickly string together services from multiple applications, even if they previously were not integrated, to support enhanced utility business processes.
Another key point from Figure 4 is that during development of the bus formulation of the web services, a comprehensive set of meter data management web services was created using the previously defined services that touched any of the functions exhibited by AMI systems. The resulting MDM service interfaces are ideally suited to facilitating extensive AMI implementations.
Which Approach: Tactical or Strategic?
Next, one should consider the approach to implementing MultiSpeak-compatible application interfaces. Depending on a utility’s needs, MultiSpeak can be simply and quickly deployed for point-to-point application integration or can serve as the basis of an enterprise service bus.
Many small utilities, or those looking for a quick solution, can use vendor-provided web services and just turn on the point-to-point interfaces. This tactical approach results in fully functional integration between two applications, often in only a few hours and at low cost. This is by far the most commonly used approach. An example of this implementation is Utility A, which purchased MultiSpeak-enabled AMI and OMS applications. In this case, no development was necessary for integration. The two applications merely needed to be set up to look for the other’s web server; integration was complete in minutes.
In some cases, utilities have one MultiSpeak-enabled application, but others with which it should be integrated do not yet have MultiSpeak interfaces. In this case, the utility or a system integrator can develop an adapter for the non-enabled application. This situation requires some development time and care to ensure that the adapter appropriately implements the MultiSpeak data model, but full integration can still be obtained for little investment. An example of this case is Utility B, which had a MultiSpeak-compatible IVR system, but their OMS did not support MultiSpeak. A system integrator was hired to write a MultiSpeak “wrapper” for the OMS. The development work was completed in a matter of weeks.
A similar situation exists where no applications have existing MultiSpeak web service interfaces. In this case, both applications to be interfaced require adapter development. Even in this more involved situation, the semantic foundation and service development work provided in MultiSpeak makes the cost of interface development small compared with what a traditional custom interface would cost for the same applications. Utility C was in this situation and completed the MultiSpeak interface development for an AMI to CIS interface using in-house programming resources.
Other utilities are beginning to look at MultiSpeak as the basis for a more strategic implementation. MultiSpeak is also well-suited to serve as the basis for a service-oriented architecture. The SOA approach has several distinct advantages that may justify the additional development time and expense:
- Uniform data model throughout the enterprise. A common semantic understanding of the data (data model) eliminates repeated data translations and misunderstandings that can result when data must be interpreted by different departments or applications with different data structures.
- A consistent set of services are available to all applications to use, even if no prior interface was defined between pairs of applications. This fact streamlines support for new business processes and enhances agility of the organization.
- The potential for reuse and flexible composition of granular web services. Once a variety of web service methods are available on the service bus, business processes can be dynamically modified (composed) to fit specific needs.
- Provisions for reliable messaging. The tactical, point-to-point approach relies on the applications on each end of the interface to be constantly available. Although some messaging reliability features are built specifically into the MultiSpeak service protocols to minimize these problems, the addition of reliable messaging in the enterprise service bus can eliminate the potential for data loss.
- Provisions for data security. Data security is becoming a necessary business practice in today’s world. Once again, MultiSpeak makes some provisions for data security using secure sockets layer (SSL) encryption and authentication, but complex application interactions may require more than just SSL for complete security. An enterprise service bus can consistently provide additional security for all data communications, enterprise-wide.
Extensions to MultiSpeak
MultiSpeak may not currently support all the applications some utilities need. For instance, since MultiSpeak was originally designed with the needs of distribution utilities in mind, power marketing and transmission network modeling are not currently supported. Development is on-going for some utility applications, such as asset management and work management.
However, MultiSpeak was designed to be extensible. It is possible to add an unlimited number of additional data objects to the data model and to extend any existing data object by the addition of an unlimited number of XML attributes and/or XML elements, all without affecting interoperation with other applications that may be unfamiliar with the thus-defined extensions. It is also possible to easily add additional web services (to support additional types of applications, such as work management) and to add new methods to existing web services. These extensibility mechanisms make it possible for a utility to build on the foundation of the MultiSpeak data model and service definitions to create those extensions necessary to meet their specific needs.
Harmonization with the Common Information Model
An alternative data model for utility integration, called the Common Information Model (CIM), is sponsored by the International Electrotechnical Commission Technical Committee 57. CIM is broader in scope than MultiSpeak but less fully developed. Many of the CIM standards’ parts have not been finalized, and, with a few minor exceptions, there are not well-defined profiles that would enable utilities to develop interoperable implementations. The emphasis in CIM development at this point is to finish standardization of the data model and the use cases to support utility business processes. Because of this emphasis, efforts have not been focused on development of services to implement those use cases.
It is likely that both standards will co-exist since both bring value to the integration equation, so there is value in working toward harmonization of the two standards. Both efforts have recognized this and have begun a concerted, mutual effort to bring the specifications together over time and develop bridging technologies to permit interoperation of applications that are compatible with the different standards.
MultiSpeak is a flexible, extensible specification that can be used as the basis for a variety of integration efforts from the simplest point-to-point interface to a complete service-oriented architecture in the largest utility. For many utilities, the MultiSpeak specification is a complete solution to their integration needs. For others it is a solution that may need some customization, but it brings a robust foundation that supports the required extension with minimal development cost and risk. Even those utilities that eventually want to transition to a CIM-based solution in the future, should consider a near-term MultiSpeak solution with a bridge to a longer-term CIM solution as CIM gains maturity.
More information about the MultiSpeak Initiative and specification can be found at www.MultiSpeak.org.
Gary A. McNaughton is vice president and principal engineer for Cornice Engineering Inc., which provides consulting services to utilities on automation and IT issues. McNaughton currently serves as project technical coordinator for NRECA’s MultiSpeak Initiative. He is a registered professional engineer in the state of Colorado. email@example.com.
Robert Saint is a principal engineer in the technical services division at the NRECA. He is a registered professional engineer in Texas and Virginia and a senior member of IEEE. At NRECA his primary role is technical advisor for the T&D Engineering Committee. He is the program manager for the MultiSpeak software integration initiative. firstname.lastname@example.org.