In September 2004, Eskom's Distribution Division Commenced a Program to Replace Five of its Regional SCADA Systems. The objective of the program was to procure and commission five commercially off-the-shelf (COTS) supervisory control and data acquisition (SCADA) systems, which included SCADA enterprise architecture integration and business-process alignment. It was extremely important that existing Eskom Distribution Division processes be supported.

A South African state-owned electric utility, Eskom (Johannesburg, South Africa) is a vertically integrated generation, transmission and distribution organization. Eskom generates and transmits 95% of the electricity used in South Africa. The Eskom Distribution Division is one of 187 electric utilities within the country responsible for distribution. This division is comprised of six organizations, or regions, each accountable for a specific geographic area. Through their wires and retail business units, the regions collectively provide power to 3.5 million customers.

CHANGE DRIVERS

The rationale for replacing the SCADA systems was a strategically driven initiative with three strong economic and business-enhancement drivers. Firstly, in the original SCADA systems, plant and asset data are captured and maintained in the respective regional geographic information systems (GIS), and are separately captured and maintained in the regional SCADA systems. SCADA-GIS integration would eliminate the second data capture and maintenance overhead.

Secondly, network operating schematics are prepared and maintained in the GIS and its supplementary Engineering Network Schematic (ENS) application, and are separately drawn and maintained in the regional SCADA systems. As with the first item, SCADA-ENS (SENS) integration would eliminate the need for the second diagram capture and maintenance overhead.

Thirdly, the replacement of the existing SCADA fault-management system and various other point-to-point interfaces with an enterprise-wide middleware alternative would reduce the long-term maintenance cost and complexity associated with the existing point-to-point integration requirements.

Importantly, a single source for plant and asset data and network schematics would improve network operational safety and lead to enhanced data quality. These are significant downstream benefits obtained through SCADA integration.

SYSTEM ARCHITECTURAL PRINCIPALS

Enterprise architecture (information systems) in Eskom Distribution strives to implement process-driven integration to enable business-process management. Establishing a semantic layer through the use of the Eskom Canonical Model was key to this implementation. Specifically, the Distribution Division decided to leverage the IEC TC57 WG14 common information model (CIM).

The CIM approach led to an integration solution with loosely coupled applications, thereby insulating application specifics from integration orchestration and transformation. Such an approach also minimizes the development of interdependencies arising between the application and system integration teams, between applications and the integration solution, and between the integration solution and external projects and/or initiatives. The figure on page 34 shows the conceptual design, including the three integration paths of the solution.

MODEL-DRIVEN INTEGRATION

The Distribution Division's integration design was based on a model-driven architecture and integration methodology. This was done to provide the following tactical and strategic advantages to the project as well as to the business as a whole:

  • To ensure consistency and scalability of the integration bus approach

  • To reduce the overall cost of integration

  • To introduce flexibility and agility in the architecture and processes

  • To ensure the business process theory and the implementation thereof are consistent (bridging the gap between the design-time and run-time environments).

To this end, we used a model-driven integration framework and tools to model the business, business processes and information exchange.

For instance, integration path No. 1 (see figure on page 34), whose design components included GE Energy's Smallworld, ENS and SENS data engineering (DE400), manages the information exchange pertaining to network asset data changes in the Smallworld application. The ENS-DE400 integration path ensures that new or modified network operating diagrams and SCADA operating diagrams (SODs) are transferred to the DE400 through the SENS interface. The information exchange primarily adopts a publish and subscribe messaging protocol, with acknowledgement of successful message delivery.

MESSAGE ARCHITECTURE

The geographic spread of the Eskom Distribution organization is such that applications exchanging information are regionally based. That is, systems are deployed regionally, running on hardware that is deployed regionally. The implementation of each regional solution required a distributed approach, which included SeeBeyond components being executed with distributed applications and application instances. Therefore, routing formed an important part of message design and construction. The publishing of messages to the respective regional application instances resulted in the need to create business routers (internal adapters) within the various SeeBeyond schemas.

SCADA DATA INTERFACE

Smallworld is the source of power-system resources and associated topology (connectivity) information. The ENS and the SENS applications will be used to generate and maintain all engineering schematic diagrams. Consequently, ENS will be the source for all SCADA diagrams and, in addition, will manage the diagram approval process.

The SCADA interface is characterized by two data types, the first of which is essentially “static” data. These long-cycle, low-frequency data transactions typically include network-type data (attributes and diagrams), insertions, updates or deletions.

To preserve the referential integrity of the SCADA database and diagrams, any modification (inserting, deleting or updating data) must be preceded by a relevant network model change. The logic to manage and enforce the required data integrity had to be incorporated in the design.

Information and diagram data changes from different sources are tagged as different “change sets.” Network model data and diagram data related to the same change event will be tagged as different change sets and rely on the relational references to update data accordingly. The challenge is not in the addition of new power-system resources, but in the changes and deletions that occur to ensure the process supports the above referential integrity.

The second SCADA data type is more dynamic in nature (high-frequency transactions). These short-cycle data transactions typically include alarms, events and status changes.

The message payload for these events is relatively small and does not compromise performance. It also requires that a guaranteed delivery of messages exists. This is essentially only a push of information to subscribing applications. Aside from the guaranteed-delivery requirement, no other BPM requirement or constraint exists.

A GREAT MANY CHALLENGES

The challenges the organization needed to overcome were greater than just the technology (systems, applications and data). To be a success, the three legs of the Eskom Information Management platform needed to exist:

Leg 1. Technology systems

From a SCADA perspective, integration required the subscription to and publishing of data to and from the enterprise middleware (SeeBeyond/Sun JavaCAPS). Significant challenges were experienced with the SCADA subscribing component of the integration initiative. Apart from these technical and organizational challenges, the publishing aspect presented few other challenges and was implemented on schedule.

Leg 2. Business processes

A timely and accurate delivery of data and network schematics required process realignment, accompanied with a significant stakeholder training intervention. An analysis and redesign of business events and triggers, timing and sequence issues, and information exchange modeling needed to be done. Issues around existing inconsistent deployment with consequential impact on data maintenance between regions posed a challenge. The business process also needed to ensure support of the 24/7 nature of the network operations environment, while the GIS organizational unit involved had a totally different (eight to five) paradigm.

Leg 3. Organization structure

Significant challenges pertaining to change management were encountered involving the embedded culture and a “not-invented-here” syndrome. The organizational structure had to be aligned with business-process changes. In some cases, questions about which organizational unit has what responsibility had to be resolved.

GIS INTEGRATION

Extraneous changes to GIS data structures and interfaces created a moving target that had huge impact on timelines. Managing and pegging the message definitions and transformation logic within a dynamic environment was an ongoing challenge. Implementing configuration and version management proved crucial to manage this continuous change.

The requirement for a persistent (connectivity) topology (switch-node) model in the GIS was identified and had to be implemented in the GIS data model. Therefore, the GIS also did not provide a graphic representation with suitable view of topology errors. So, we had to make a topology viewer available, expressing the topology in a GXL format that was viewable through graphical viewers.

The solution also required the development of a Change Set Manager application for the management, synchronization and dissemination of incremental network data and network schematic diagram changes.

GOING FORWARD

With the development phase now complete, implementation will be commencing soon. When this occurs, the integration solution will be exposed to the rigors and constraints of the organization's business processes. We anticipate meeting the ultimate challenge: The integration solution will enhance the business processes and, as a consequence, service levels.


John Hope-Sotherton is currently project manager for the Eskom Distribution DMS project. He is member of the Eskom Enterprises Protection, Telecontrol and Measurements organization and is responsible for the provision of SCADA services to the Eskom line businesses. hopesoj@eskom.co.za

Shannon Naidoo is chief integration architect in the Eskom Distribution Information Management organization, where she is responsible for the development and execution of distribution information management strategy. shannon.naidoo@eskom.co.za

Johann Marx is an integration architect in the Eskom Distribution Information Management organization, where he is responsible for all aspects of the distribution network asset creation business process.
johann.marx@eskom.co.za

Phillip Jones specializes in the design, development and implementation of integration solutions for Xtensible Solutions Inc. He is contracted by Eskom as an integration consultant, and is accountable for the design and development of the distribution SCADA integration solution.
pjones@xtensible.net

INTEGRATION CHALLENGE

The Smallworld (SW) schema represented 149 objects in a 35,000-line XML schema. The challenge was to map to and transform this schema to a CIM-based schema (NetworkDataSet). The SW schema was generated by code, but due to an unfinalized data model, it was based on conceptual objects. Data-model changes were driven by external projects, and together with the need to continuously improve the quality of the generated schema, resulted in the creation of a new schema every other week. This created a constantly moving target. Delaying the SCADA project until he GIS system was finalized was also not an option.

Due to the sheer size of the SW schema, several tests and experiments were conducted before a specific tool or methodology was selected. The initial intent was to use XSLT as the medium to develop and store the transformation logic, thereby giving the adapter a much more adaptive and flexible design. The SW team was not familiar with XSLT technology and the particular design pattern, and at first preferred to stick with a Java code-based approach. The team agreed to do some real-world testing before making a final decision.

The EAI design tool creates a Java data model from the respective schema, which creates a list of nodes, each with its own Object ID. The SW team experienced some corruption problems with the transformation code (when the number of elements mapped got too high), which required restarting the work each time. Changes to the SW schema also meant restarting the mapping effort each time. This became unsustainable.

Using XSLT provided more flexibility to deal with constant changes. Non-EAI (nonproprietary) tools could be used for the mapping to overcome EAI designer problems. These included Altova Mapforce, which captures the mapping rules in XML format.

A further issue was the generation of large temporal Java classes, which caused the Java Virtual Machine to crash. No amount of setting changes could fix this, so the team had to use the XSLT Template option to overcome this problem.

Adapter transformation logic was easy to update via XSLT. Configuration management of artefacts is now easier to do as well (XSLT and XML schema). This also ties into the enterprise information management strategy.