| GISdevelopment.net ---> GITA 1998 ---> SCADA and Real-Time Systems |
Beyond GIS - a New Level of Integration
Peter M. Batty
Smallworld Systems, Inc.
5600 Greenwood Plaza Blvd.
Englewood, CO 80111
Peter M. Batty
Smallworld Systems, Inc.
5600 Greenwood Plaza Blvd.
Englewood, CO 80111
Overview
Integration of AM/FM/GIS with other applications is critical to gain maximum business benefits from the system. The big drive in utilities and telecommunication companies is to re-engineer work processes and improve their efficiency. A single work process may involve interaction with many different applications and databases, such as customer information systems, GIS, outage management, SCADA, and work management.
This paper begins by looking at some examples of application integration to give some idea of the sort of problems which need to be addressed. The main focus of this paper is the integration of AM/FM/GIS with other spatial/network systems - specifically outage management and SCADA. In order to understand the reasons that organizations typically have multiple systems for spatial/network applications such as AM/FM/GIS, outage management and SCADA, the main features of these applications are summarized, and the similarities and differences between them are examined. Various approaches to integrating spatial/network applications are discussed, followed by a brief examination of some issues relating to integration with non-spatial applications.
Application Integration Examples
There are many situations in which integration between applications can provide benefits by streamlining work processes and providing additional functionality. For example, an outage management application needs to be integrated with the customer information system to receive trouble calls made by customers, and to provide feedback to customer service representatives on the current state of outages. It also needs to be integrated with the network design application, typically implemented within the AM/FM/GIS, to keep up to date with the latest changes to the network. Both outage and design applications may need to be integrated with a work management system, to initiate and track either scheduled construction work, or emergency repairs.
The main focus of this paper is on approaches to integrating the three main spatial/network applications in a utility: AM/FM/GIS, outage management and SCADA.
Types of Spatial/Network Applications
AM/FM/GIS
Major applications of AM/FM/GIS in a typical utility or telecommunications company typically include:
Outage Management
Outage management has a high profile in the electric industry. It involves analyzing calls from customers to identify probable failing devices and dispatching crews to fix these problems. The ability to handle dynamic network switching, and to track outage history for customers and devices, are other key requirements. In telecommunications, dispatch aspects of the application are similar, but device predictions are typically generated by devices themselves sending alarms across the network.
This is a short transaction application, in which any changes (for example, to the outage status of a customer) should be visible to all users immediately. This is in contrast to the design environment mentioned in the previous section, where changes made by a designer should not be propagated to all users immediately.
Outage management has demanding performance requirements, both in terms of call processing and in terms of screen redraw. Large utilities may need to process and analyze 30,000 calls per hour or more. Not all network devices are of interest to the outage management application, so it is common to use an aggregated network model containing fewer devices than the AM/FM/GIS for this application. Outage management is a mission critical system, which needs to be running on a 7x24 basis.
Traditional AM/FM/GIS systems have been unable to handle the performance and availability requirements of outage management, which has led to the development of specialist standalone outage management systems. The source of data for the outage system is the AM/FM/GIS, so an interface needs to be developed between the two.
SCADA / Network Management
SCADA (Supervisory Control and Data Acquisition) systems, or network management systems (NMS), are used to directly monitor and control devices on the network. These are genuinely real time systems, in a way in which outage management systems are not. Outage management might be termed a “near real time” system - the state of the world modeled by the outage system is a predicted view of the real world, and it may lag events in the real world by several minutes, as it builds a picture primarily based on customer calls. In contrast, an NMS system has an accurate and completely up to date view of the world because it is communicating directly with network devices.
This means that NMS has some different technical requirements from outage management. In particular, the status of devices on screen must change immediately when information is received by the NMS system. In contrast, with outage management it is acceptable for users to refresh the screen periodically to see the latest state of the predicted outages. This means that some sort of messaging system is required for NMS, which notifies all client applications that they need to update themselves immediately.
NMS of course is also a mission critical system which needs to support 7x24 operation.
Simple mapping / viewing app lications
All of the preceding applications usually run on reasonably well-configured machines. However, much of the information they manage is useful to many people throughout the organization, so there is a strong requirement to be able to access it on any desktop throughout the organization, via some kind of “thin client” application. The most common and convenient way of delivering such thin client applications to every desktop in an organization is via a web browser.
In addition to simply accessing underlying data, there may be metadata or functionality in the more complex applications which it would be very useful to access from these thin client applications. This could range from simple things like using common symbology definitions, to more complex things like running a load flow analysis on a thin client.This issues are discussed later, in the section on distribution of spatial/network data and services.
Similarities and Differences Between Spatial/Network Applications
Traditionally, AM/FM/GIS, outage management, and SCADA have been three independent applications. Some of the reasons for this were mentioned in the previous section.
The first is that the database transaction models are fundamentally different for these systems, with AM/FM/GIS needing long transactions, outage management needing short transactions, and SCADA needing real time transactions with messaging.
A second difference is in the requirements for redraw performance. SCADA users generally demand sub-second redraws. SCADA systems are typically dealing with the smallest amount of data of the three systems, so this is achievable, usually by storing graphics structures in memory. While all users would like redraw to be as fast as possible, for outage management something like a 5 second redraw is acceptable in most situations, and for AM/FM applications a 10-15 second redraw is often acceptable. However, both of these applications need to handle a larger amount of graphical data than a typical SCADA application. These differing requirements in terms of both redraw speed and graphical data volumes have traditionally made it difficult to accommodate all three systems in a common environment.
However, there are clearly a number of similarities between these three applications. All need to access a model of the network and display it graphically. There is a lot of common functionality, such as the ability to pan and zoom, select objects and view their attributes, and carry out various network tracing functions.
If these three systems could be combined, this would achieve a number of benefits, depending on the exact approach used. These include an integrated workflow for the end user, for tasks which required the use of more than one system; reduced costs and maximized usage of skills by having a common development and system administration environment; and reduced database maintenance requirements through having a single database to update.
Spatial/Network Integration Approaches
There are various possible approaches to integrating the different spatial/network systems, and these are discussed in this section. Some of these are alternative approaches, and some can be used in conjunction with each other.
Rerdication
The AM/FM/GIS is usually the system in which changes to the network due to new construction are entered. These changes need to be accessible in the outage or SCADA systems. The technique of database replication is a useful tool for achieving this. The outage or SCADA system may work against a completely different underlying Database Management System (DBMS) from the GIS, or it may work against different data structures within the same DBMS. For example, outage management systems do not require such a detailed network model as AM/FM, so for performance reasons the outage system may construct an aggregated (higher level) view of the network.
The diagram shows the steps involved in database replication in this sort of scenario. This sort of replication runs on a periodic basis (typically nightly) to propagate changes in the as built network, which are entered in the AM/FM/GIS, into the real time model used by the outage and/or SCADA systems. There is often a lag of several days in getting as built changes back to the AM/FM/GIS, which is why periodic replication is an appropriate model.
A critical element of this sort of replication is the ability to robustly and efficiently propagate incremental changes from one database to another. Repopulating the whole database is not a practical proposition on a daily basis, with the data volumes which are involved. With any form of replication, it is crucial to ensure that integrity is always maintained between the two databases, even if the synchronization job fails when it is partly completed. In the situation under consideration here, it is also necessary that the replication process can restructure objects (for example, creating an aggregated view of the network in a different format), while satisfying the requirement of propagating incremental changes in a robust way. In general, an approach which involves direct access to both databases, rather than one based on file passing, provides a much more robust solution. The ability to automatically track changes and yield the changed records (inserts, updates and deletes) should be a standard function of any AM/FM/GIS database which is used in this situation.
Distinct systems
The simplest way to use replication is just to run independent systems against the two databases. This is the most straightforward to implement of all the options mentioned here, but it does not offer the advantages of the more integrated approaches which are mentioned below. In some cases it may be possible to run both systems on the same workstation, but in others it may be necessary to have separate workstations for each system. In general, SCADA and outage management systems have been slower to move from Unix to Windows NT than AM/FM/GIS systems have.
Common user interface
A more integrated approach is to use two separate engines for AM/FM/GIS and for outage or SCADA, but to present the user with a common user interface which accesses functionality and displays data from both underlying systems. This approach is illustrated in the diagram below.
This approach allows work processes to be significantly streamlined compared to using two separate systems - functionality from both environments is available to the user. The user can also see data from both systems, so the more detailed data which is stored in the GIS can be displayed as a backdrop to the higher level network data used in the outage or SCADA system. This more detailed data can be very useful in a variety of situations. For example, in outage management applications, a call maybe received from the police or fire service to report an outage caused by an accident (such as a car hitting a pole). Such reports will be tied to a geographical address rather than directly to a device in the electrical network, and therefore they often cannot be handled in traditional outage management systems, which just store a high level representation of the network.
The cleanest way of integrating multiple engines in an environment like this is by using distributed object technology. The two main distributed object architectures are the Object Management Group’s CORBA (Common Object Request Broker Architecture), and Microsoft’s COM (Common Object Model). For an example of using this approach to integrating AM/FM/GIS and SCADA/NMS, using CORBA, see Herger and Goede (1996).
Common spatial app lication environment
A drawback of the preceding approach is that it uses two different environments for application development and system administration. Application functions which are written in one environment may not run against the network data structures of the other environment.
This approach takes integration one stage further and provides a single spatial application development environment, which is used to implement AM/FM/GIS, outage management, and SCADA functionality. This development environment can access data from any of the underlying systems. Although this development environment is shown as a single box in the diagram, it could be a number of components interacting in a distributed object environment.
This allows functionality which is required in all three environments, such as basic network tracing or load flow analysis, to be implemented just once. In addition, functionality developed by the vendor can be justified across the user base for all the applications. For example, many specialist outage vendors have a user base of 10-20 customers, whereas the major GIS vendors have a user base of hundreds or thousands of organizations. This means that a GIS vendor can much more easily justify development of generic new functionality, such as web browser support, than the more specialized vendors. In an integrated environment like this, these generic capabilities can also be taken advantage of with the outage and SCADA applications.
Distribution of Spatial/Network Data and Services
As mentioned earlier, there is a requirement to be able to access spatial/network data and functionality on any desktop throughout an organization. Most early spatial web products focused on serving simple graphical data to the desktop. Even those products which provide more sophisticated spatial analysis capabilities are not typically integrated with the high end GIS which is used for complex AM/FM/GIS applications, outage management, etc. What is really required to streamline workflows and distribute functionality to where it is needed, throughout the organization, is an application server which allows the same sophisticated functionality which is developed in the main AM/FM/GIS environment to be run via a web browser. The key to this is to allow the AM/FM/GIS to run as an application server, and allow its functionality to be accessed via distributed object technology such as ActiveX.
Non-Spatial Intergration
Most of the discussion in this paper has focused on integration of the three main spatial/network applications in a utility: AM/FM/GIS, outage management and SCADA. However, integration of non-spatial systems such as work management and customer information systems is also critical to re-engineering work processes and gaining maximum benefits from the AM/FM/GIS. Traditionally this sort of integration has been implemented using low level protocols such as SQL to access different databases. While there will continue to be a role for SQL for some time, the latest trend is to use distributed object technology, such as CORBA, to implement this sort of integration.
The common spatial application environment described earlier can simplify the implementation of integrated systems. For example, significant benefits can be gained by integrating work management with both design applications in AM/FM/GIS and with outage management. If the AM/FM/GIS and outage systems are both implemented in the same environment, then the same interface can be used for both systems, rather than having to develop two separate interfaces.
Conclusions
Historically, utilities have had to implement separate systems for AM/FM/GIS, outage management and SCADA/Network Management. Technology is now reaching the stage where it is practical to integrate all of these systems in a single environment. This offers significant benefits in terms of usability, additional functionality, and development, implementation and system administration costs. Distributed object technology is one of the enabling tools for this integration, and we will see this used increasingly for integration between AM/FM/GIS and other spatial and non-spatial applications.
References
Integration of AM/FM/GIS with other applications is critical to gain maximum business benefits from the system. The big drive in utilities and telecommunication companies is to re-engineer work processes and improve their efficiency. A single work process may involve interaction with many different applications and databases, such as customer information systems, GIS, outage management, SCADA, and work management.
This paper begins by looking at some examples of application integration to give some idea of the sort of problems which need to be addressed. The main focus of this paper is the integration of AM/FM/GIS with other spatial/network systems - specifically outage management and SCADA. In order to understand the reasons that organizations typically have multiple systems for spatial/network applications such as AM/FM/GIS, outage management and SCADA, the main features of these applications are summarized, and the similarities and differences between them are examined. Various approaches to integrating spatial/network applications are discussed, followed by a brief examination of some issues relating to integration with non-spatial applications.
Application Integration Examples
There are many situations in which integration between applications can provide benefits by streamlining work processes and providing additional functionality. For example, an outage management application needs to be integrated with the customer information system to receive trouble calls made by customers, and to provide feedback to customer service representatives on the current state of outages. It also needs to be integrated with the network design application, typically implemented within the AM/FM/GIS, to keep up to date with the latest changes to the network. Both outage and design applications may need to be integrated with a work management system, to initiate and track either scheduled construction work, or emergency repairs.
The main focus of this paper is on approaches to integrating the three main spatial/network applications in a utility: AM/FM/GIS, outage management and SCADA.
Types of Spatial/Network Applications
AM/FM/GIS
Major applications of AM/FM/GIS in a typical utility or telecommunications company typically include:
- Planning and design of network changes: this requires the ability to handle so called “long transactions”, in which the changes made by a designer are not visible to other users of the system until it is appropriate - which may be days or weeks (see Newell and Easterfield, 1990).
- Detailed map production: maps which show the exact location of facilities relative to detailed landbase data are usually a product of the AM/FM/GIS. This is the most detailed level of data which is required by any of the spatial/network applications.
- Asset management: this function maybe partly or wholly carried out within the AM/FM/GIS, covering areas such as inspection and maintenance information, tracking asset value and utilization, etc.
Outage Management
Outage management has a high profile in the electric industry. It involves analyzing calls from customers to identify probable failing devices and dispatching crews to fix these problems. The ability to handle dynamic network switching, and to track outage history for customers and devices, are other key requirements. In telecommunications, dispatch aspects of the application are similar, but device predictions are typically generated by devices themselves sending alarms across the network.
This is a short transaction application, in which any changes (for example, to the outage status of a customer) should be visible to all users immediately. This is in contrast to the design environment mentioned in the previous section, where changes made by a designer should not be propagated to all users immediately.
Outage management has demanding performance requirements, both in terms of call processing and in terms of screen redraw. Large utilities may need to process and analyze 30,000 calls per hour or more. Not all network devices are of interest to the outage management application, so it is common to use an aggregated network model containing fewer devices than the AM/FM/GIS for this application. Outage management is a mission critical system, which needs to be running on a 7x24 basis.
Traditional AM/FM/GIS systems have been unable to handle the performance and availability requirements of outage management, which has led to the development of specialist standalone outage management systems. The source of data for the outage system is the AM/FM/GIS, so an interface needs to be developed between the two.
SCADA / Network Management
SCADA (Supervisory Control and Data Acquisition) systems, or network management systems (NMS), are used to directly monitor and control devices on the network. These are genuinely real time systems, in a way in which outage management systems are not. Outage management might be termed a “near real time” system - the state of the world modeled by the outage system is a predicted view of the real world, and it may lag events in the real world by several minutes, as it builds a picture primarily based on customer calls. In contrast, an NMS system has an accurate and completely up to date view of the world because it is communicating directly with network devices.
This means that NMS has some different technical requirements from outage management. In particular, the status of devices on screen must change immediately when information is received by the NMS system. In contrast, with outage management it is acceptable for users to refresh the screen periodically to see the latest state of the predicted outages. This means that some sort of messaging system is required for NMS, which notifies all client applications that they need to update themselves immediately.
NMS of course is also a mission critical system which needs to support 7x24 operation.
Simple mapping / viewing app lications
All of the preceding applications usually run on reasonably well-configured machines. However, much of the information they manage is useful to many people throughout the organization, so there is a strong requirement to be able to access it on any desktop throughout the organization, via some kind of “thin client” application. The most common and convenient way of delivering such thin client applications to every desktop in an organization is via a web browser.
In addition to simply accessing underlying data, there may be metadata or functionality in the more complex applications which it would be very useful to access from these thin client applications. This could range from simple things like using common symbology definitions, to more complex things like running a load flow analysis on a thin client.This issues are discussed later, in the section on distribution of spatial/network data and services.
Similarities and Differences Between Spatial/Network Applications
Traditionally, AM/FM/GIS, outage management, and SCADA have been three independent applications. Some of the reasons for this were mentioned in the previous section.
The first is that the database transaction models are fundamentally different for these systems, with AM/FM/GIS needing long transactions, outage management needing short transactions, and SCADA needing real time transactions with messaging.
A second difference is in the requirements for redraw performance. SCADA users generally demand sub-second redraws. SCADA systems are typically dealing with the smallest amount of data of the three systems, so this is achievable, usually by storing graphics structures in memory. While all users would like redraw to be as fast as possible, for outage management something like a 5 second redraw is acceptable in most situations, and for AM/FM applications a 10-15 second redraw is often acceptable. However, both of these applications need to handle a larger amount of graphical data than a typical SCADA application. These differing requirements in terms of both redraw speed and graphical data volumes have traditionally made it difficult to accommodate all three systems in a common environment.
However, there are clearly a number of similarities between these three applications. All need to access a model of the network and display it graphically. There is a lot of common functionality, such as the ability to pan and zoom, select objects and view their attributes, and carry out various network tracing functions.
If these three systems could be combined, this would achieve a number of benefits, depending on the exact approach used. These include an integrated workflow for the end user, for tasks which required the use of more than one system; reduced costs and maximized usage of skills by having a common development and system administration environment; and reduced database maintenance requirements through having a single database to update.
Spatial/Network Integration Approaches
There are various possible approaches to integrating the different spatial/network systems, and these are discussed in this section. Some of these are alternative approaches, and some can be used in conjunction with each other.
Rerdication
The AM/FM/GIS is usually the system in which changes to the network due to new construction are entered. These changes need to be accessible in the outage or SCADA systems. The technique of database replication is a useful tool for achieving this. The outage or SCADA system may work against a completely different underlying Database Management System (DBMS) from the GIS, or it may work against different data structures within the same DBMS. For example, outage management systems do not require such a detailed network model as AM/FM, so for performance reasons the outage system may construct an aggregated (higher level) view of the network.
The diagram shows the steps involved in database replication in this sort of scenario. This sort of replication runs on a periodic basis (typically nightly) to propagate changes in the as built network, which are entered in the AM/FM/GIS, into the real time model used by the outage and/or SCADA systems. There is often a lag of several days in getting as built changes back to the AM/FM/GIS, which is why periodic replication is an appropriate model.
A critical element of this sort of replication is the ability to robustly and efficiently propagate incremental changes from one database to another. Repopulating the whole database is not a practical proposition on a daily basis, with the data volumes which are involved. With any form of replication, it is crucial to ensure that integrity is always maintained between the two databases, even if the synchronization job fails when it is partly completed. In the situation under consideration here, it is also necessary that the replication process can restructure objects (for example, creating an aggregated view of the network in a different format), while satisfying the requirement of propagating incremental changes in a robust way. In general, an approach which involves direct access to both databases, rather than one based on file passing, provides a much more robust solution. The ability to automatically track changes and yield the changed records (inserts, updates and deletes) should be a standard function of any AM/FM/GIS database which is used in this situation.
Distinct systems
The simplest way to use replication is just to run independent systems against the two databases. This is the most straightforward to implement of all the options mentioned here, but it does not offer the advantages of the more integrated approaches which are mentioned below. In some cases it may be possible to run both systems on the same workstation, but in others it may be necessary to have separate workstations for each system. In general, SCADA and outage management systems have been slower to move from Unix to Windows NT than AM/FM/GIS systems have.
Common user interface
A more integrated approach is to use two separate engines for AM/FM/GIS and for outage or SCADA, but to present the user with a common user interface which accesses functionality and displays data from both underlying systems. This approach is illustrated in the diagram below.
This approach allows work processes to be significantly streamlined compared to using two separate systems - functionality from both environments is available to the user. The user can also see data from both systems, so the more detailed data which is stored in the GIS can be displayed as a backdrop to the higher level network data used in the outage or SCADA system. This more detailed data can be very useful in a variety of situations. For example, in outage management applications, a call maybe received from the police or fire service to report an outage caused by an accident (such as a car hitting a pole). Such reports will be tied to a geographical address rather than directly to a device in the electrical network, and therefore they often cannot be handled in traditional outage management systems, which just store a high level representation of the network.
The cleanest way of integrating multiple engines in an environment like this is by using distributed object technology. The two main distributed object architectures are the Object Management Group’s CORBA (Common Object Request Broker Architecture), and Microsoft’s COM (Common Object Model). For an example of using this approach to integrating AM/FM/GIS and SCADA/NMS, using CORBA, see Herger and Goede (1996).
Common spatial app lication environment
A drawback of the preceding approach is that it uses two different environments for application development and system administration. Application functions which are written in one environment may not run against the network data structures of the other environment.
This approach takes integration one stage further and provides a single spatial application development environment, which is used to implement AM/FM/GIS, outage management, and SCADA functionality. This development environment can access data from any of the underlying systems. Although this development environment is shown as a single box in the diagram, it could be a number of components interacting in a distributed object environment.
This allows functionality which is required in all three environments, such as basic network tracing or load flow analysis, to be implemented just once. In addition, functionality developed by the vendor can be justified across the user base for all the applications. For example, many specialist outage vendors have a user base of 10-20 customers, whereas the major GIS vendors have a user base of hundreds or thousands of organizations. This means that a GIS vendor can much more easily justify development of generic new functionality, such as web browser support, than the more specialized vendors. In an integrated environment like this, these generic capabilities can also be taken advantage of with the outage and SCADA applications.
Distribution of Spatial/Network Data and Services
As mentioned earlier, there is a requirement to be able to access spatial/network data and functionality on any desktop throughout an organization. Most early spatial web products focused on serving simple graphical data to the desktop. Even those products which provide more sophisticated spatial analysis capabilities are not typically integrated with the high end GIS which is used for complex AM/FM/GIS applications, outage management, etc. What is really required to streamline workflows and distribute functionality to where it is needed, throughout the organization, is an application server which allows the same sophisticated functionality which is developed in the main AM/FM/GIS environment to be run via a web browser. The key to this is to allow the AM/FM/GIS to run as an application server, and allow its functionality to be accessed via distributed object technology such as ActiveX.
Non-Spatial Intergration
Most of the discussion in this paper has focused on integration of the three main spatial/network applications in a utility: AM/FM/GIS, outage management and SCADA. However, integration of non-spatial systems such as work management and customer information systems is also critical to re-engineering work processes and gaining maximum benefits from the AM/FM/GIS. Traditionally this sort of integration has been implemented using low level protocols such as SQL to access different databases. While there will continue to be a role for SQL for some time, the latest trend is to use distributed object technology, such as CORBA, to implement this sort of integration.
The common spatial application environment described earlier can simplify the implementation of integrated systems. For example, significant benefits can be gained by integrating work management with both design applications in AM/FM/GIS and with outage management. If the AM/FM/GIS and outage systems are both implemented in the same environment, then the same interface can be used for both systems, rather than having to develop two separate interfaces.
Conclusions
Historically, utilities have had to implement separate systems for AM/FM/GIS, outage management and SCADA/Network Management. Technology is now reaching the stage where it is practical to integrate all of these systems in a single environment. This offers significant benefits in terms of usability, additional functionality, and development, implementation and system administration costs. Distributed object technology is one of the enabling tools for this integration, and we will see this used increasingly for integration between AM/FM/GIS and other spatial and non-spatial applications.
References
- Herger, K., and Goede, S., 1996: Integration of GIS and NMS; what are the benefits? Smallworld International Conference Proceedings.
- Newell, R.G., and Easterfield, M. E., 1990: Version Management - the problem of the long transaction. Proceedings of the Mapping Awareness conference.