San Bernard Electric Cooperative, a rural cooperative distribution utility in southeast Texas, recognized the time, expense, and difficulty inherent in connecting a host of disparate, internal, customized systems that had been independently developed and were not interoperable.

The utility decided to implement the National Rural Electric Cooperative Association-sponsored and trademarked MultiSpeak® specification, which is the de facto standard for data exchanges among enterprise application software commonly applied in utilities. The foundation of the specification is an agreement on the details of the data objects that need to be exchanged to more fully integrate disparate software applications. It is intended to assist vendors and utilities in developing interfaces that enable software products from a variety of vendors to interoperate without the need for extensive custom interface development.

The systems targeted for integration via the MultiSpeak specification included a metering system (in transition), an outage management system, a customer information system and a geographic information system, among others. The specification documents how interfaces between these systems may be used to implement utility business processes in over 300 standard use cases, thus reducing the time required for implementing MultiSpeak-compatible integrations.

The utility’s decision on implementing the MultiSpeak specification coincided with its decision to transition from a power line carrier-based automated meter reading system to an advanced metering infrastructure system in a manner that would leverage the supplementary functionality provided by the new metering technology.

The utility found that cost/benefit calculations to build a business case with positive return on investment were difficult to conduct prior to implementation. Instead, the initial proposal to utility management rested on the credibility and experience of utility specialists and on their qualitative assessment of the benefits.

Post-implementation tracking of benefits, however, has established that operational efficiencies and related, customer service improvements justify the time and cost of implementing the MultiSpeak specification. Specifically, the MultiSpeak specification was successful in automating a host of hitherto manual functions, which significantly improved interoperability and led to cost savings in terms of reduced field operations/truck rolls as well as other benefits.

The MultiSpeak installation and commissioning process provided a host of lessons learned which will be useful to other utilities embarking on similar projects.

When the utility realized that the MultiSpeak specification would not address all of its integration needs, the utility identified which applications it could immediately incorporate into its MultiSpeak-enabled suite of applications. For unaddressed integration needs, the utility sought to learn whether those gaps would be addressed by future development by the sponsoring National Rural Electric Cooperative Association and/or vendors.

Further, in the integration of an advanced metering infrastructure system, an outage management system and the customer information system, some incompatibilities required custom coded-application programming interfaces to achieve interoperability, which were developed internally.

Pay careful attention to software issues relating to iterative versions. A vendor that is ‘MultiSpeak compliant’ doesn’t mean that the vendor’s system can integrate seamlessly with MultiSpeak-compliant systems the utility already has in place. Different vendors may be running different versions, so it is important to understand the capabilities and limitations of the version of the MultiSpeak specification that your vendor is supporting, especially as versions are not backwards compatible.

A MultiSpeak implementation demands well-understood, even required responsibilities internal and external to the utility. Internally, the team must grasp the utility’s business processes and functions that integration and automation are expected to support. For external parties, including vendors, interoperability should be broadly defined; software iterations should not be specified. Instead, procurement requirements should focus on the business processes being supported and integrated. Requests for proposals, contract awards, service level and maintenance agreements and testing documentation should explicitly place responsibility on vendors for a) participating in MultiSpeak development activities, b) maintaining interoperability, c) interoperability testing and documentation.

• Beyond documentation, the procuring utility must assess the methods within the interoperability affirmation/assertion documentation to ensure that the testing address their required business functions. In fact, interoperability testing between utility systems should be contractually required as part of system-acceptance testing. Vendors must guarantee that functionalities in current system offerings needed to support utility business processes continue to be supported in future versions.

Implementing company overview
San Bernard Electric Cooperative (SBEC) is a rural cooperative distribution utility in southeast Texas. It covers an area approximately 96 miles long by 35 miles wide. It was formed in 1939 when several leaders from Austin and Colorado counties became interested in securing service for their farms. The cooperative derives its name from the San Bernard River, which is the common boundary between Austin and Colorado counties.

SBEC has 26,000 metered customers, 78 miles of transmission, 16 substations with supervisory control and data acquisition (SCADA) control and monitoring and four offices across seven counties. It utilizes microwave backhaul between its offices and substations. Figure 1, SBEC’s service area, west of Houston, Texas.

Figure 1: San Bernard Electric Cooperative’s service area
(click to enlarge)
 

Business challenge
In the early days at SBEC, a large amount of customization was required to transport data from one operating system to the other. The utility had a spider web of custom solutions (see Figure 2). Over time, technologies evolved requiring even more customization. SBEC found itself deploying more and more customized solutions, adding further to the siloed nature of solution-specific data flows within the utility.

One example of this evolution was in automated meter reading (AMR). SBEC had used a power line carrier (PLC) AMR solution since 1988. More recently, before implementing MultiSpeak Specification Version 3.0 (See Appendices B, C and D for details), the utility deployed a new Sensus AMI wireless system in place of the older PLC AMR system. The problem was that the new AMI system was not interoperable with the utility’s existing customer information system (CIS) and geographic information system (GIS)/outage management system (OMS) systems. This incompatibility created unexpected operating issues. For example, in the creation and receipt of numerous alerts and alarms, not all of them had the same time-sensitivity, creating an unscreened information overload for SBEC system operators.

SBEC realized that it was no longer tenable or productive to operate its spider web of customized solutions and it decided to transition to standardized data flows to create a more interoperable operating system. At this point, SBEC examined the MultiSpeak specification as a solution; management understood the benefits of interoperability. SBEC began its journey of untangling its spider web by replacing each process with the MultiSpeak specification, with the goal of creating an interoperable suite of applications.

Figure 2: Numerous customized applications shifted to one interoperable system by implementing the MultiSpeak specification
 

Solution description
When the utility realized that the MultiSpeak specification would not address all of its integration needs, SBEC set out to identify which applications it could immediately incorporate into its MultiSpeak suite of applications.

Where it was determined that the MultiSpeak specification did not meet all of its needs, SBEC set up discussions with its vendors and with the MultiSpeak specification’s sponsor – the National Rural Electric Cooperative Association (NRECA) – to ascertain if future development would fill those gaps. For example, in deploying the smart meters of its new AMI system, SBEC was using machine-to-machine (M2M) batch processing in some cases – the ‘ship file’ that came with each shipment of meters was batch-dumped into the inventory system, a National Information Solutions Cooperative-developed application. The data management for the new-for-old meter exchange followed processes that paralleled the deployment processes in the field.

SBEC uses a daily interval reading that batch uploads to the billing system. This is a custom query with scheduled tasks inside of Standardized Query Language (SQL). For the meter data management system (MDMS), California Metering Exchange Protocol (CMEP) and Meter Level Alarms (MLA) standards are used. Alarms are sent to the OMS and field viewers through custom SQL. Blink counts are gathered and stored as a daily reading to an SQL table. Operators run deltas against the blink counts and compare them to outages in the area to determine what actions are needed to improve the quality of service. For this process to work smoothly and cohesively, the utility’s Information Technology (IT) department had to be intimate with all of the relevant enterprise systems, business processes and data exchanges.

The installation of the MultiSpeak specification automated the meter exchange from the field device data base to the CIS.

SBEC included MultiSpeak methods to:

• update meter changes to the AMI and OMS applications,
• allow for self-reporting of outages from the AMI to the OMS before a phone call from a customer could occur,
• automate the connect/disconnect process from the CIS/billing system to the AMI system,
• notify the OMS in real-time when a meter had been disconnected for non-payment and
• notify the OMS when an account on the pre-payment option had been disconnected due to insufficient funds.

The automation of these functions prevented unnecessary trips by utility linemen.

Using the MultiSpeak specification, the interactive voice response (IVR) is notified about outages from the OMS when a phone call is received. Engineering analysis (EA) receives energy usage from the AMI system through the MultiSpeak specification.

Some custom SQL integrations were required in this implementation scenario. These custom integrations can be challenging, depending on the willingness of vendors to allow access to their proprietary schema protocols and tables that enable the custom integrations.

Examples of custom SQL coding that were developed by SBEC include:

• auto-posting of alarms into Milsoft’s OMS package,
• a permanent historical record of all alarms, outages and phone calls at individual locations,
• provision of a meter alarm to the operator’s field viewer, and
• creation of a system email to communicate alarms to the utility’s meter department.

In an upcoming issue, Part II will discuss MuiltiSpeak analytics and alarms using OMS and field viewer; SBEC’s AMI smart metering and alarm interpretation; interoperability-related lessons learned from SBEC’s implementation; and general recommendations to industry.

About the Authors

Doug Lambert is the Senior Principle of Distribution Engineering and System Automation with the National Rural Cooperative Association, an organization of more than 900 not-for-profit rural electric cooperatives and public power districts providing retail electric service to more than 42 million consumers. Previously, Doug worked with the San Bernard Electric Cooperative in Texas for 15 years as an IT manager and SCADA and engineering data supervisor, among other roles.

Dominic Geraghty is a senior consultant with the Smart Grid Interoperability Panel, a member-funded organization that engages Smart Grid stakeholders to create national standards and advance interoperability, Dominic has spent over 20 years working to advance the grid. He has been a general partner at a venture capital fund and worked in a large private equity fund, both focused solely on energy deals. He currently serves as managing editor of SmartGridiX and as executive chairman of both Smart Energy Instruments and N-Dimension Solutions.