By Dirk Altenhoff, Gary Hitzfelder and Paul Skare
City Public Service of San Antonio (CPS) is the second largest municipal utility in the United States, serving more than a half-million electric customers and more than 300,000 natural gas customers. In 1999 when the Texas Legislature passed a law restructuring the state’s electric utility industry, CPS opted out but continued to prepare for the possibility of competition.
With this direction in mind, CPS embarked on a number of new projects. While the modernization of its enterprise resource planning (ERP) tool with SAP for Utilities was the largest effort, CPS also addressed automation needs within the transmission and distribution control centers: upgrading its workforce management system, streamlining its geographical information system (GIS), and introducing an outage management system (OMS).
Moreover, CPS decided to integrate these applications to increase their usefulness. However, with the uncertainty of a deregulated market ahead, CPS recognized the importance of flexibility and scalability of its IT landscape. CPS wanted to integrate certain systems, but did not want to become captive in a rigid environment where any future change would be costly and time-consuming.
Integration can be accomplished in many ways. Traditionally, direct point-to-point connections are used to exchange data, trigger events, etc. This type of integration requires knowledge only of the systems to be integrated. Even more importantly, in the case of homegrown systems, it can be performed internally. The downside is that with each new application the number of potentially necessary connections rises drastically and so does the effort to maintain them. The created interface is proprietary to the two systems it connects and may require modifications if one of the two systems changes.
Vendors of large software systems sometimes favor a different approach. They would prefer customers buy everything from one source. This approach basically eliminates the need for integration, as all applications are part of one large system. However, the same vendors usually offer little when new applications need to be integrated down the road or, even worse, when a part of the comprehensive system has to be replaced.
Sometimes integration problems are addressed by offering interfaces based on messaging technology. This typically involves a point-to-point connection, but it’s a step in the right direction since provision of a standardized application programming interface (API) eases integration. The flexibility of this solution varies greatly. Some implementations are configurable; other are rather rigid and meet only specific integration needs.
Yet another approach is motivated by the desire for a single point of data entry. A single point of data entry avoids duplicated efforts to create and maintain data as well as problems related to different applications using different versions of the same data set. One way to implement this feature is to have a single database that joins data from different applications. Obviously, this database can become large and difficult to maintain. There also may be performance issues related to this approach.
CPS avoided all these problems by employing Enterprise Integration Bus (EIB) technology. The EIB is based on messaging software to exchange data between applications, but strictly adheres to the principle of “publish-and-subscribe.” In a nutshell, information holders publish to the “public,” and interested parties receive the information by “subscribing” to it. Another important cornerstone of the architecture is to funnel all communication through so-called component adapters, thus providing an additional layer of separation between applications. There are no point-to-point connections.
With EIB technology in place, each application requires what is called an “application wrapper.” The wrapper functions as an application-specific API that provides the necessary hooks to retrieve and supply data or trigger to and from the application. The wrapper is only proprietary to one application.
The wrapper itself does not communicate with other applications. The component adapters take care of this function by exchanging data blocks with other adapters using middleware and messaging. Strict publish-and-subscribe is used to achieve maximum flexibility. Publish-and-subscribe means that messages are not sent from one application directly to another but instead are published on the bus. Applications that need the published data subscribe to it. This way multiple applications can receive the same information. There are no point-to-point connections, and there is no interdependence between data formats across applications as messages are in XML format. There is no need to adjust applications or application interfaces because of changes to the data format. Figures 1 and 2 depict the principles of this architecture.
The messaging technology selected by CPS is IBM’s WebSphere MQSeries. The WebSphere product suite also includes the WebSphere MQSeries Integrator, a message broker. The message broker adds flexibility to the infrastructure as it provides message transformation and routing functionality. CPS utilizes the broker to set up the publish-and-subscribe network rather than having it hard-coded in the adapters. This makes it possible to add or remove a subscriber without changing code.
Message transformation and translation is used to adjust data between applications. An example would be date and time formats, as some applications prefer a format like MM/DD/YYYY HH:MM:SS, while others count seconds since a certain point in time. The transformation could be done in the adapters, but using the broker adds some flexibility and keeps the adapters simpler.
Another transformation occurs when equipment identifiers are exchanged between applications. For example, the OMS uses a 4-step technological address consisting of four 8-character strings; the ERP system requires a functional locator; and the GIS identifies equipment by the so-called MSLink, a numeric number. The benefit of performing transformations and translations in the broker is added flexibility. Neither the sender nor the recipient of a message needs to worry about data format.
Figure 3 gives an overview of the architecture of the EIB at City Public Service.
Control Center Automation
Besides the aforementioned benefits of integrating applications using EIB technology, CPS also aims at achieving a higher level of automation in its control center, primarily for planned and unplanned outages. To follow, are examples:
In case of a customer reporting an outage, the OMS receives a call notification from the Customer Care System (CCS), an SAP module. The OMS processes the notification and creates an outage record. It also sends a list of de-energized transformers back to the CCS. The OMS then allows the system operator to create job orders relevant to the outage record. These orders are sent to Plant Maintenance (PM), also an SAP module. PM processes the data and sends a work order to the mobile workforce management system where a field crew will be dispatched to investigate and perform necessary work to rectify the outage. Work order status updates are sent back to the OMS and PM. Should the system operator decide to close the outage record based on the work order status, notifications are sent to the CCS so power restoration can be verified with customer callbacks.
For outages detected by the SCADA system, a network topology processor identifies whether there is any de-energized part in the system. The OMS creates outage records for de-energized parts of the system. Further processing is similar to outages initiated by customer calls.
Processing for planned outages begins with a notification from the work management system to Plant Maintenance identifying the transformers subject to maintenance work. PM creates work orders and sends a notification to the OMS to create an outage record. The system operator studies network conditions and impact using the applications provided as part of the distribution management system (DMS) and if necessary revises the transformer list. A switching procedure is generated and attached to the outage record. During the execution period, similar activities as stated for outages initiated by customer calls or SCADA are performed.
The introduction and integration of new applications drastically changed the way CPS processes outages. Information is exchanged between applications automatically, and manual data entry is held to a minimum, resulting in higher data quality and reduced response time for outages.
The integration is also a cost saving measure for CPS. Accurate one-lines showing current network information are crucial to the usefulness of the DMS. Years ago, the control center depended on hand-drawn maps. These were replaced with printed maps from an automated mapping system, which were made available to system operators. Today, CPS is replacing the mapping system with a GIS that will be the source of the data. The new GIS should automatically provide updates to the DMS as soon as the update has been made to the GIS database. The same GIS also will provide data to other systems. This is a cost saving to CPS as labor-intensive data maintenance only occurs in the GIS database and not in multiple systems. It also reduces the likelihood of problems related to mismatched data between different systems.
EIB’s introduction implies tighter coupling of outage management, mobile workforce management, automated mapping/facilities management, work management, and the ERP solution as described above. Using adapters and the publish-and-subscribe method also effectively de-couples the applications from one another without hampering integration capability. The adapters shield the applications from the outside world and separate them from one another by defining standardized interfaces between them.
This architecture establishes an environment where applications can be added, replaced or modified with no impact on other applications. For example, if CPS decided to upgrade its GIS, an upgrade would impact the GIS and its wrapper. None of the other applications that interface with the GIS would need to be changed.
Through integration, CPS has achieved improved customer service, better reliability and cost savings. But the low-cost and quick deployment capability toward future needs was the driving force behind CPS’ decision to implement EIB technology.
- Application data is consistent and shared across department boundaries
- Any integrated application can be replaced or upgraded without causing a ripple effect
- The cost for maintaining the interfaces is lower going forward.
CPS is well prepared for the challenges of retail competition. With the very flexible and scalable EIB solution, it can respond quickly and with low cost to future requirements.
Dirk Altenhoff started his career with PRODV where he developed GIS solutions for utilities before he joined Siemens in 1997 where he was responsible for EAI business. He can be reached at email@example.com
Gary Hitzfelder began work at City Public Service, San Antonio, in 1974 as a transmission planning engineer and was promoted to senior engineer of transmission planning in 1982. He is currently manager of control systems. Hitzfelder is a registered Professional Engineer in Texas and an IEEE member.
Paul M. Skare is manager of SCADA development for Siemens Power Transmission and Distribution, Energy Management and Information Systems Division. Paul is a technical expert for the International Electrotechnical Committee, in Technical Committee 57, Working Group 7 that defines the standards for TASE.2 (ICCP).