| GISdevelopment.net ---> GITA 1998 ---> SCADA and Real-Time Systems |
Integrating DMS and GIS The Time Has Come
Tony Sileo
Director of Product Development GeoData Solutions, Inc.
8620 Wolff Court Suite 250
Westminster, Colorado 80030
tony@igeodata-gis.com
http://geodata-gis.com
Tony Sileo
Director of Product Development GeoData Solutions, Inc.
8620 Wolff Court Suite 250
Westminster, Colorado 80030
tony@igeodata-gis.com
http://geodata-gis.com
Introduction
This paper fmt provides an overview of the key features and requirements of a Distribution Management System (DMS). It then explores the advantages of a DMS that is tightly integrated with a Geographic Information System (GIS). Next, the paper presents a database architecture that combines the benefits of long transaction GIS databases with the efilciency and scalability of conventional short transaction databases. Finally, the paper shares key results and conclusions fi-om a proof-of- concept laboratory and discusses progress since its completion and plans for the future.
Features of a DMS
A Distribution Management System provides control, troubleshooting and analysis of an electric power distribution network. Performing these fimctions well requires reliable, eff]cient interfaces with many other utility information systems. A successful DMS must include a fast, well-organized, intuitive user interface as well as fimdamental network modeling and analysis capabilities. Finally, the DMS must be available 24 hours a day, 7 days a week, and it must maintain acceptable performance under the highest load conditions. See (Briody 1997) for an excellent overview of DMS functionality.)
Interface with Other Information Systems
A full-featuredDMS will include well-defined interfaces for exchanging data and interacting with some or all of the utility information systems listed in this section. In general, an open database architecture with well-defined application programming interfaces will provide the most adaptable, extensible approach to systems integration. For each system, the description includes key data items and indicates whether those items are inputs or outputs of the DMS. Ideally, all data should be pushed to its destination(s) from the system that creates the data (the source). This is the most efficient approach and avoids time lags and wasted resources introduced by polling processes that have to watch for new data and pull it from the source to the destination.
Geogmphic Information System(GE)
The DMS must build an initial connectivity model of the as-built distribution network from data available in the GIS. The DMS also needs the ability to easily recognize changes to the as-built network and update the connectivity model to reflect those changes, without impacting current operations. The GIS also provides the geographic location of the distribution facilities, along with reference landbase data. h may also contain one-line schematics or other circuit diagrams required by DMS users. Ideally, all data in the GIS should be available to as needed to users of the DMS.
The GIS will often also include customer connection information, either via a customer of transformer relationship, or more often via direct connectivity (secondary network, service cables, meter locations, etc.). The DMS must be capable of extracting and maintaining this information in order to correctly associate customer trouble calls with the location of each customer in the network.
Finally, DMS users must have the ability to indicate permanent changes in the electric network. These permanent changes should be reflected in the GIS database so that mappers and design engineers are aware of the current position of devices in the field.
Customer Information System(CIS)
TheDMS must be able to accept customer trouble call information from the CIS. These will either be entered manually by customer service representatives (call takers) or automatically using an Interactive Voice Response (IVR) system. Most calls will include a unique customer identifier that links the customer into the DMS network model. The system also must handle non-customer calls in an appropriate manner.
The customer service representatives and IVR would like to obtain current outage status information from the DMS as individual customers call in (e.g., expected restoration time). The DMS must also be able to generate customer call lists for planned outages or customer callback lists to help verify outage restorations.
Supervisory Control and Data Acquisition (SCADA) and Distribution Automation(DA)
TheDMS should be able to accept confirmed device operations from the SCADA or DA system. This information can either confirm outages or restorations. In some cases, these maybe momentary outages that would otherwise not even register in the system (these are still important for historical statistics and reporting). In some cases (particularly with the impending advent of distribution automation), DMS users will also want the ability to directly operate automated devices.
Mobde Data Terminals (MDT) and Computer Aided Dispatch (CAD)
Manyelectricutilitiesplan to improve efficiency and cut operational costs providing crews in the field with direct access to information in the DMS. With a well-designed interface between the DMS and MDT system, dispatchers can focus on prioritizing resources across multiple projects (emergencies, outages, switching procedures, service requests, etc.) while the crews manage the step-by-step details of each project. The interface must be able to list prioritized work orders on the MDT and allow crew and device status changes from the field.
Automated Meter Reading System (AMR)
If the utility implements an AMR system that includes a fixed or radio based network, the DMS can take advantage of this rich data source to confirm customer restorations and improve the accuracy of device prediction. The DMS can easily generate a list of key meters to poll (e.g., one per transformer) in order to confirm predictions or locate “hidden” outages downstream of a protective device that operated.
Corporate Intranet (Executive Information System, Media Relations)
Corporate executives, public relations officials, and other non-DMS users would like to have live access to current DMS information, such as summary statistics, short-term trends, and overview maps. Providing an intranet-based solution to this requirement can avoid the need for the DMS users to spend precious time communicating with management during storm situations.
Network Analysis Software
DMS usersneed seamless access to network analysis software for load calculations in order to simulate switching plans used during outage restoration, construction or repair work, or seasonal load balancing.
Work Management System (WMS)
ln some cases, the DMS will need to receive daily crew rosters from a work management system. The DMS also maybe required to initiate permanent repair work orders in the WMS.
Interruption Reporting/Outage History System
In order to fulfill regulatory reporting requirements and provide a data archive for internal system analysis and legal liability applications, the DMS must record the time and source of key system activities in a flexible, well-organized data archive. This archive will include trouble calls, outages, customer interruptions, device operations, and crew activities. Ideally, the DMS will also be capable of “playing back” the sequence of activities that resulted tlom an identified event (such as a thunderstorm). This feature is invaluable for training and testing, as well as tuning work processes and automated system rules (device prediction, crew assignment).
Future Information Systems
In addition, in the deregulated utility industry of tomorrow, a successful DMS may need to interface with information systems from other utility business units such as transmission, power generation, and energy delivery (customer interaction). These interfaces may be through systems similar to those listed above or through new or hybrid systems that evolve with the industry.
User Functionality
A DMS user interface must support a variety of important fimctions, each used with varying frequency and demand, but all critical to the overall success of the product.
Mapping
Users need quick access to intelligent, geographically and electrically accurate system maps and circuit schematics. The maps must include both network facilities and kind base data. The facilities must be accurately located with respect to each other and the land base and must include all the attribute data required by dispatchers and system operators to perform their jobs. This includes phasing information, current and normal operating state, and equipment type. Display styles and symbols should easily differentiate various types of equipment, operating states, power states, and feeder numbers. In short, a good DMS requires all the functionality of any modem AMiFM/GIS.
The map also must be tightly integrated with other user interface components to provide an efllcient, seamless view of the network, crews, and outages to the dispatchers and distribution system operators.
Outage Management
Themost critical fimction performed by a DMS in areas with predominantly overhead electric distribution is outage management. Repairing faults and restoring power as quickly and efllciently as possible are critical tasks in tomorrow’s deregulated utility environment. The DMS must aHow dispatchers to quickly assess the likely cause and extent of outages, determine options for restoring power, and provide timely outage status to the customer service center. It should also provide estimated restoration times based on experience, standard repair times, input from crews and current crew workload. Finally, dispatchers or crews need to enter causes, remarks and other outage information before data is written to the outage archive.
This interface must be extremely efficient and as automated as possible, for it is most critical at the time of maximum demand - during severe storms or other widespread outage scenarios. The system should be able to predict the most likely cause (device) of each outage, based on the location of trouble calls in the network and the current state of other connected network devices.
Crew Management
Thesystem should allow dispatchers to manage all of the company’s mobile assets, including trouble crews, repair crews, service crews, and many others. These assets may be either company-owned or contracted. The system should display the current status and location of all available crews on the map and also in textual form. Dispatchers need the ability to assemble crews tlom vehicles and crew members, assign work to crews, indicate crew and device status changes reported via voice communications, and close out crew work orders upon completion.
Additionally, a well-designed DMS will provide an easy-to-configure interface to more sophisticated crew management systems, such as Computer Aided Dispatch or Mobile Data Terminals. In many cases, these other systems are better suited to provide the complex scheduling, accounting, and crew management timctions required by a large utility. As such, the DMS should work in conjunction with the crew management system to form a complete solution for the end user.
System Operations
All of the other system operations performed and monitored in the dispatch center will actually form the largest percentage of DMS use. Service order dispatching, emergency repairs, seasonal load switching, constructionhepair switching, and planned outages are all managed by this same system. These functions must be part of the same interface used to manage outages and crews.
The system should include easy-to-read summaries of current system status, including customers out, abnormal switches, work-in-progress, and outage locations (planned and unplanned). Equipment “tags”, duplicating the colored push-pins and tags used on the wall maps in many dispatch centers, must be integrated with all aspects of DMS operation. The system should provide as much intelligence as possible to help users organize critical information and make informed decisions.
Network Modeling Capabilities
A DMS must be capable of storing and maintaining a generic connected flow model of the electric network. True geographic facility locations are also a necessity for outage and crew management.
The data in the model must be organized to provide very high-speed device prediction during high-volume storm situations. It must also enable efllcient re-configuration to reflect new connectivity resulting from switching operations. The users will need to view and interact with the as-built or as-designed (GIS), as-planned (switching plans), and as-is (real-time) state of the distribution network.
Ideally, the DMS will be tightly integrated with network load analysis soflware to provide immediate feedback on the effect of planned switching operations and outage conditions.
Architectural Requirements
The critical nature and high data volumes of this application drive very harsh reliability and performance requirements into the system architecture. A DMS, or at least the outage management portion of it, must provide 7x24 availability. Large utilities expect the system to process at least 30,000 trouble calls per hour fi-om the CIS, while simultaneously interacting with up to 40 concurrent users at multiple geographically separated sites. The users and external systems perform switching operations that re-configure the dynamic connectivity of the network. Each site must have local access to all DMS data, as it must take over operations from other sites in the case of WAN or hardware failures.
Furthermore, a viable DMS must provide ideal performance at maximum system load. The system should experience little or no performance degradation even when operating at the extreme edge of design requirements. In other words, when a storm hits and trouble call volume goes through the roof, the DMS must be operating at peak performance, as that is the time when dispatchers need the most efllcient operations. This is different from most applications, where performance may be allowed to degrade linearly as system load increases. A DMS cannot be designed to operate well under 99.9% of the load conditions – the other 0.1% is exactly when it is most important for the system to provide reliable and efficient operation.
The near real-time nature of the data used by a DMS, as well as the multi-site, concurrent use requirements mentioned above, dictate the need for a short transaction data repository. By contrast, most GIS applications require so-called “long transactions,” where one user’s changes are not visible to other users until the design is complete (days or weeks). It is possible to use long transaction databases in a short transaction mode as in (Steinmeyer, Sileo 1996) and (Volhnar 1997). However, this solution does not scale well and falls well short of the transaction rates and number of concurrent users expected of the DMS for a medium to large size utility. This leads to the easy conclusion that DMS data is best stored in a standard short transaction database. Conveniently, the major short transaction DBMS’s on the market (Oracle and Sybase) both provide multi-site asynchronous replication as well as high data throughput operations.
Advantages of GIS-Based DMS
Leverage Existing GIS Investments
Choosing and implementing a GIS involves a significant investment on the part of any electric utility. By using a GIS-based DMS, much of this investment can be re-used, rather than duplicated for the DMS. Some of the more obvious examples of re-usable investments are:
Most of the current commercially available DMS products operate with an extracted model of the electric network. Generating this extract and keeping it current ofien becomes a major implementation headache. At one utility, the implementation team estimated almost 2 months of continuous CPU time just to extract the initial network model from the GIS. Continuing updates to keep the two systems synchronized were potentially not possible within available time fames (overnight). This headache is largely avoided by tightly coupling the DMS with the GIS. The initial extract of the DMS model and each subsequent incremental update is much easier to manage due to the tight integration. As an added benefit, the complete GIS data set is also available on demand to DMS operators.
Take Advantage of Rich GIS Product Functionality
The larger user base of a GIS product company provides a very solid product development and support environment, rather than encouraging one-off custom development. A DMS product must provide many of the same mapping, database and user interface fimctions as a GIS. A GIS company can use its large user base to support a richer set of built-in functionality as well as a solid support, testing, training, and documentation infrastructure. Stand-alone DMS vendors are easily influenced by one or two large customers, leading to customized solutions rather than generic products.
Potential Disadvantages of GIS-Based DMS
Screen Redraw
GIS applications typically have less stringent screen redraw requirements than a near real time application such as DMS. DMS users typically require complete screen redraw after pan or zoom operations to take less than five seconds. The level of detail and rendering flexibility available in a GIS are provided at the cost of screen redraw performance. Integrating DMS with GIS can lead to unacceptably slow screen redraws, particularly during high-volume scenarios, when the dispatchers need the system to be as quick as possible.
Unfortunately, most existing DMS products that provide very fast screen redrawing do so through extensive use of memory caches and/or map partitioning. This strategy drives up the cost of client workstations (often requiring hundreds of megabytes of RAM) and also leads to very complex cache coherency strategies. Keeping the client caches up to date often requires a complicated messaging system that can easily saturate the network during high-volume scenarios (exactly when you want to avoid extra network traffic). Map partitions (i.e., non-seamless databases) lead to figmented data that can be diftlcult to maintain and update.
InteractionsBetween Short and Long Tmnsaction Data
Changes to the “as-is” DMS database occur over short time spans (on the order of seconds or less) and need to be propagated to other users as quickly as possible. Every user needs to see the same version of the “as-is” database. In other words, a DMS uses and generates short transaction data that is accessed by multiple concurrent users. This is significantly different tiom a typical GIS, where data changes occur over long time spans (hours or days) and other users do not want to see changes until they are completed and approved. Synchronizing the long transaction GIS database and the short transaction DMS database is a critical task. Completed GIS changes must be propagated to the DMS database as quickly and efficiently as possible, without intermpting on-going DMS operations. Note, however, that these potential problems affect any DMS, regardless of how tightly it is integrated with the GIS.
Custom Application vs. Product
There is a danger that any application with multiple interfaces and site-specific data will become a custom solution that only works for a particular GIS data model, or in a particular client environment. Many of the currently available DMS solutions have fallen into this trap. Each new installation starts from the most recently completed version of the system, rather than are-usable base product. Implementing product upgrades becomes an increasing nightmare as more and more sites are brought on-line. rather than are-usable base product. Implementing product upgrades becomes an increasing nightmare as more and more sites are brought on-line.
An Architecture for Success
Between April and July 1997,two industry vendors and a using utility jointly conducted a technical proof-of-concept laboratory. The main goal of the laboratory was to ensure that all key fictional and performance requirements could be met by a new proposed GIS-based DMS architecture. A description of the laboratory approach and results follow.
Database Architecture
The basic database architecture used during the laboratory consisted of a read-only version of the GIS database and two linked partitions containing the DMS database, as portrayed in Figure 1. The DMS database was split into static and dynamic partitions in order to take advantage of the object-oriented database and spatial indexing schemes of the GIS, while still providing a short transaction repository for the dynamic DMS data.
The short transaction database used in the laboratory was Sybase, although recent testing has also used Oracle. This basic architecture was repeated at each separate dispatch site, as in Figure 2. Appropriate replication strategies are employed in this architecture to propagate data changes between sites. During the lab, we only tested the short transaction database replication, since replication was seen as a straightforward implementation. Although we only simulated two sites in the lab, extending this database architecture to additional sites presents no particular difficulties.
Figure 1. Basic Database Architecture
Hardware Configuration
During the lab, we started with a very simple test environment and then added components piece-by-piece until we reached the configuration shown in Figure 3. In addition to the database components discussed above, a CIS trouble call table was also present in the short transaction database. Trouble calls were inserted into this table at one of the sites by a simulation.
Figure 2. Multiple Dispatch Sites
tool called the “Trouble Call Playback” engine. These call records were replicated to all other sites via the short transaction replication. Each site also ran its own “trouble retriever” process. This process was responsible for retrieving trouble calls from the CIS and perform device prediction.
Figure 3- Final Hardware Configuration
Laboratory Results
Performance Testing
Three basic test scenarios were run on each hardware configuration used during the lab. A simulation tool generated these scenarios by modeling customer calls downstream of a set of failed devices. The tool allowed various parameter settings, such as the percentage of affected customers that actually call to report the outage and how long after the outage begins until they actually call. Another tool simulated dispatcher activities on the system by assigning crews to outages and cycling outages and crews through the outage restoration process.
Availability Testing
In order to test system availability in the event of a hardware or network failure, one of the Sybase servers was shut down while running a test. The second server was allowed to continue for some time, and then the fmt server was rebooted. The goal was to verifi that the second server continued to run with no problems when the fmt went down, and that re-synchronization occurred correctly and efficiently when the first server came back on line.
Results and Conclusions
After several weeks of setup and tuning, the team achieved roughly 8,000 trouble calls per hour through a single “trouble retriever” (including device prediction) during the laboratory. More recent tuning and testing indicates the potential of 25,000 calls per hour per retriever. Changing the interface so that the CIS pushes calls into the DMS, allowing the DMS to concentmte on device prediction, is expected to further improve call throughput. By nmning parallel retrievers (or prediction engines), throughput rates of over 100,000 calls per hour are attainable. The laboratory testing also simulated up to I dispatcher action every six seconds with no significant impact on the trouble call throughput rate.
The availability testing was also successful. One of the Sybase servers was shut down for a total of 18 minutes while the second server continued to operate. When the server was restarted, approximately 40 MB of data had to be replicated across the WAN from the second server. This re-synchronization took approximately 14 minutes. It is expected that improvement on this performance will be realized by using stored procedures to execute many of the bulk update activities (only the procedure invocation is replicated, rather than each individual data change).
Summary and Current Progress
In summaty, this paper presented the basic functionality and interfaces required of a Distribution Management System (DMS). It then explored the advantages and disadvantages of tightly integrating a DMS with a GIS. From these, it is easy to see the desirability of building a DMS product on top of a GIS. Results from a proof-of-concept laboratory go fhrther to show the feasibilityof this integration. Cost savings via shared technology and infrastructure investments, plus increased functionality and a robust, flexible development environment, make GIS the perfect choice for a DMS product platform. Note that the architecture presented in this paper does not strictly require that the GIS data reside a GIS proprietary database. With the advent of Open GIS and the incorporation of same into the GIS vendor offerings, data from any GIS database can be accessed and integrated with the DMS.
Previously, utilities expected to pay millions of dollars in licensing and implementation services for a custom DMS solution. These solutions were not tme products – upgrades were rare and difilcult to install. Maintaining consistent data in the DMS and GIS was a nearly impossible task. With this new approach, these same utilities can expect to pay less than half the cost of other systems to buy and install a DMS product. Such products should include regular, easy-to-install upgrades, dedicated technical supporL and considerable commonality with the GIS database, user interface, and support infrastructure.
Bibliography and Additional Reading
This paper fmt provides an overview of the key features and requirements of a Distribution Management System (DMS). It then explores the advantages of a DMS that is tightly integrated with a Geographic Information System (GIS). Next, the paper presents a database architecture that combines the benefits of long transaction GIS databases with the efilciency and scalability of conventional short transaction databases. Finally, the paper shares key results and conclusions fi-om a proof-of- concept laboratory and discusses progress since its completion and plans for the future.
Features of a DMS
A Distribution Management System provides control, troubleshooting and analysis of an electric power distribution network. Performing these fimctions well requires reliable, eff]cient interfaces with many other utility information systems. A successful DMS must include a fast, well-organized, intuitive user interface as well as fimdamental network modeling and analysis capabilities. Finally, the DMS must be available 24 hours a day, 7 days a week, and it must maintain acceptable performance under the highest load conditions. See (Briody 1997) for an excellent overview of DMS functionality.)
Interface with Other Information Systems
A full-featuredDMS will include well-defined interfaces for exchanging data and interacting with some or all of the utility information systems listed in this section. In general, an open database architecture with well-defined application programming interfaces will provide the most adaptable, extensible approach to systems integration. For each system, the description includes key data items and indicates whether those items are inputs or outputs of the DMS. Ideally, all data should be pushed to its destination(s) from the system that creates the data (the source). This is the most efficient approach and avoids time lags and wasted resources introduced by polling processes that have to watch for new data and pull it from the source to the destination.
Geogmphic Information System(GE)
The DMS must build an initial connectivity model of the as-built distribution network from data available in the GIS. The DMS also needs the ability to easily recognize changes to the as-built network and update the connectivity model to reflect those changes, without impacting current operations. The GIS also provides the geographic location of the distribution facilities, along with reference landbase data. h may also contain one-line schematics or other circuit diagrams required by DMS users. Ideally, all data in the GIS should be available to as needed to users of the DMS.
The GIS will often also include customer connection information, either via a customer of transformer relationship, or more often via direct connectivity (secondary network, service cables, meter locations, etc.). The DMS must be capable of extracting and maintaining this information in order to correctly associate customer trouble calls with the location of each customer in the network.
Finally, DMS users must have the ability to indicate permanent changes in the electric network. These permanent changes should be reflected in the GIS database so that mappers and design engineers are aware of the current position of devices in the field.
Customer Information System(CIS)
TheDMS must be able to accept customer trouble call information from the CIS. These will either be entered manually by customer service representatives (call takers) or automatically using an Interactive Voice Response (IVR) system. Most calls will include a unique customer identifier that links the customer into the DMS network model. The system also must handle non-customer calls in an appropriate manner.
The customer service representatives and IVR would like to obtain current outage status information from the DMS as individual customers call in (e.g., expected restoration time). The DMS must also be able to generate customer call lists for planned outages or customer callback lists to help verify outage restorations.
Supervisory Control and Data Acquisition (SCADA) and Distribution Automation(DA)
TheDMS should be able to accept confirmed device operations from the SCADA or DA system. This information can either confirm outages or restorations. In some cases, these maybe momentary outages that would otherwise not even register in the system (these are still important for historical statistics and reporting). In some cases (particularly with the impending advent of distribution automation), DMS users will also want the ability to directly operate automated devices.
Mobde Data Terminals (MDT) and Computer Aided Dispatch (CAD)
Manyelectricutilitiesplan to improve efficiency and cut operational costs providing crews in the field with direct access to information in the DMS. With a well-designed interface between the DMS and MDT system, dispatchers can focus on prioritizing resources across multiple projects (emergencies, outages, switching procedures, service requests, etc.) while the crews manage the step-by-step details of each project. The interface must be able to list prioritized work orders on the MDT and allow crew and device status changes from the field.
Automated Meter Reading System (AMR)
If the utility implements an AMR system that includes a fixed or radio based network, the DMS can take advantage of this rich data source to confirm customer restorations and improve the accuracy of device prediction. The DMS can easily generate a list of key meters to poll (e.g., one per transformer) in order to confirm predictions or locate “hidden” outages downstream of a protective device that operated.
Corporate Intranet (Executive Information System, Media Relations)
Corporate executives, public relations officials, and other non-DMS users would like to have live access to current DMS information, such as summary statistics, short-term trends, and overview maps. Providing an intranet-based solution to this requirement can avoid the need for the DMS users to spend precious time communicating with management during storm situations.
Network Analysis Software
DMS usersneed seamless access to network analysis software for load calculations in order to simulate switching plans used during outage restoration, construction or repair work, or seasonal load balancing.
Work Management System (WMS)
ln some cases, the DMS will need to receive daily crew rosters from a work management system. The DMS also maybe required to initiate permanent repair work orders in the WMS.
Interruption Reporting/Outage History System
In order to fulfill regulatory reporting requirements and provide a data archive for internal system analysis and legal liability applications, the DMS must record the time and source of key system activities in a flexible, well-organized data archive. This archive will include trouble calls, outages, customer interruptions, device operations, and crew activities. Ideally, the DMS will also be capable of “playing back” the sequence of activities that resulted tlom an identified event (such as a thunderstorm). This feature is invaluable for training and testing, as well as tuning work processes and automated system rules (device prediction, crew assignment).
Future Information Systems
In addition, in the deregulated utility industry of tomorrow, a successful DMS may need to interface with information systems from other utility business units such as transmission, power generation, and energy delivery (customer interaction). These interfaces may be through systems similar to those listed above or through new or hybrid systems that evolve with the industry.
User Functionality
A DMS user interface must support a variety of important fimctions, each used with varying frequency and demand, but all critical to the overall success of the product.
Mapping
Users need quick access to intelligent, geographically and electrically accurate system maps and circuit schematics. The maps must include both network facilities and kind base data. The facilities must be accurately located with respect to each other and the land base and must include all the attribute data required by dispatchers and system operators to perform their jobs. This includes phasing information, current and normal operating state, and equipment type. Display styles and symbols should easily differentiate various types of equipment, operating states, power states, and feeder numbers. In short, a good DMS requires all the functionality of any modem AMiFM/GIS.
The map also must be tightly integrated with other user interface components to provide an efllcient, seamless view of the network, crews, and outages to the dispatchers and distribution system operators.
Outage Management
Themost critical fimction performed by a DMS in areas with predominantly overhead electric distribution is outage management. Repairing faults and restoring power as quickly and efllciently as possible are critical tasks in tomorrow’s deregulated utility environment. The DMS must aHow dispatchers to quickly assess the likely cause and extent of outages, determine options for restoring power, and provide timely outage status to the customer service center. It should also provide estimated restoration times based on experience, standard repair times, input from crews and current crew workload. Finally, dispatchers or crews need to enter causes, remarks and other outage information before data is written to the outage archive.
This interface must be extremely efficient and as automated as possible, for it is most critical at the time of maximum demand - during severe storms or other widespread outage scenarios. The system should be able to predict the most likely cause (device) of each outage, based on the location of trouble calls in the network and the current state of other connected network devices.
Crew Management
Thesystem should allow dispatchers to manage all of the company’s mobile assets, including trouble crews, repair crews, service crews, and many others. These assets may be either company-owned or contracted. The system should display the current status and location of all available crews on the map and also in textual form. Dispatchers need the ability to assemble crews tlom vehicles and crew members, assign work to crews, indicate crew and device status changes reported via voice communications, and close out crew work orders upon completion.
Additionally, a well-designed DMS will provide an easy-to-configure interface to more sophisticated crew management systems, such as Computer Aided Dispatch or Mobile Data Terminals. In many cases, these other systems are better suited to provide the complex scheduling, accounting, and crew management timctions required by a large utility. As such, the DMS should work in conjunction with the crew management system to form a complete solution for the end user.
System Operations
All of the other system operations performed and monitored in the dispatch center will actually form the largest percentage of DMS use. Service order dispatching, emergency repairs, seasonal load switching, constructionhepair switching, and planned outages are all managed by this same system. These functions must be part of the same interface used to manage outages and crews.
The system should include easy-to-read summaries of current system status, including customers out, abnormal switches, work-in-progress, and outage locations (planned and unplanned). Equipment “tags”, duplicating the colored push-pins and tags used on the wall maps in many dispatch centers, must be integrated with all aspects of DMS operation. The system should provide as much intelligence as possible to help users organize critical information and make informed decisions.
Network Modeling Capabilities
A DMS must be capable of storing and maintaining a generic connected flow model of the electric network. True geographic facility locations are also a necessity for outage and crew management.
The data in the model must be organized to provide very high-speed device prediction during high-volume storm situations. It must also enable efllcient re-configuration to reflect new connectivity resulting from switching operations. The users will need to view and interact with the as-built or as-designed (GIS), as-planned (switching plans), and as-is (real-time) state of the distribution network.
Ideally, the DMS will be tightly integrated with network load analysis soflware to provide immediate feedback on the effect of planned switching operations and outage conditions.
Architectural Requirements
The critical nature and high data volumes of this application drive very harsh reliability and performance requirements into the system architecture. A DMS, or at least the outage management portion of it, must provide 7x24 availability. Large utilities expect the system to process at least 30,000 trouble calls per hour fi-om the CIS, while simultaneously interacting with up to 40 concurrent users at multiple geographically separated sites. The users and external systems perform switching operations that re-configure the dynamic connectivity of the network. Each site must have local access to all DMS data, as it must take over operations from other sites in the case of WAN or hardware failures.
Furthermore, a viable DMS must provide ideal performance at maximum system load. The system should experience little or no performance degradation even when operating at the extreme edge of design requirements. In other words, when a storm hits and trouble call volume goes through the roof, the DMS must be operating at peak performance, as that is the time when dispatchers need the most efllcient operations. This is different from most applications, where performance may be allowed to degrade linearly as system load increases. A DMS cannot be designed to operate well under 99.9% of the load conditions – the other 0.1% is exactly when it is most important for the system to provide reliable and efficient operation.
The near real-time nature of the data used by a DMS, as well as the multi-site, concurrent use requirements mentioned above, dictate the need for a short transaction data repository. By contrast, most GIS applications require so-called “long transactions,” where one user’s changes are not visible to other users until the design is complete (days or weeks). It is possible to use long transaction databases in a short transaction mode as in (Steinmeyer, Sileo 1996) and (Volhnar 1997). However, this solution does not scale well and falls well short of the transaction rates and number of concurrent users expected of the DMS for a medium to large size utility. This leads to the easy conclusion that DMS data is best stored in a standard short transaction database. Conveniently, the major short transaction DBMS’s on the market (Oracle and Sybase) both provide multi-site asynchronous replication as well as high data throughput operations.
Advantages of GIS-Based DMS
Leverage Existing GIS Investments
Choosing and implementing a GIS involves a significant investment on the part of any electric utility. By using a GIS-based DMS, much of this investment can be re-used, rather than duplicated for the DMS. Some of the more obvious examples of re-usable investments are:
- Support personnel and infrastructure
- Trainers and training facilities
- GIS software licenses
- Data translation or conversion
- Design, development, and testing of custom GIS applications
- Installation and maintenance of a development environment
Most of the current commercially available DMS products operate with an extracted model of the electric network. Generating this extract and keeping it current ofien becomes a major implementation headache. At one utility, the implementation team estimated almost 2 months of continuous CPU time just to extract the initial network model from the GIS. Continuing updates to keep the two systems synchronized were potentially not possible within available time fames (overnight). This headache is largely avoided by tightly coupling the DMS with the GIS. The initial extract of the DMS model and each subsequent incremental update is much easier to manage due to the tight integration. As an added benefit, the complete GIS data set is also available on demand to DMS operators.
Take Advantage of Rich GIS Product Functionality
The larger user base of a GIS product company provides a very solid product development and support environment, rather than encouraging one-off custom development. A DMS product must provide many of the same mapping, database and user interface fimctions as a GIS. A GIS company can use its large user base to support a richer set of built-in functionality as well as a solid support, testing, training, and documentation infrastructure. Stand-alone DMS vendors are easily influenced by one or two large customers, leading to customized solutions rather than generic products.
Potential Disadvantages of GIS-Based DMS
Screen Redraw
GIS applications typically have less stringent screen redraw requirements than a near real time application such as DMS. DMS users typically require complete screen redraw after pan or zoom operations to take less than five seconds. The level of detail and rendering flexibility available in a GIS are provided at the cost of screen redraw performance. Integrating DMS with GIS can lead to unacceptably slow screen redraws, particularly during high-volume scenarios, when the dispatchers need the system to be as quick as possible.
Unfortunately, most existing DMS products that provide very fast screen redrawing do so through extensive use of memory caches and/or map partitioning. This strategy drives up the cost of client workstations (often requiring hundreds of megabytes of RAM) and also leads to very complex cache coherency strategies. Keeping the client caches up to date often requires a complicated messaging system that can easily saturate the network during high-volume scenarios (exactly when you want to avoid extra network traffic). Map partitions (i.e., non-seamless databases) lead to figmented data that can be diftlcult to maintain and update.
InteractionsBetween Short and Long Tmnsaction Data
Changes to the “as-is” DMS database occur over short time spans (on the order of seconds or less) and need to be propagated to other users as quickly as possible. Every user needs to see the same version of the “as-is” database. In other words, a DMS uses and generates short transaction data that is accessed by multiple concurrent users. This is significantly different tiom a typical GIS, where data changes occur over long time spans (hours or days) and other users do not want to see changes until they are completed and approved. Synchronizing the long transaction GIS database and the short transaction DMS database is a critical task. Completed GIS changes must be propagated to the DMS database as quickly and efficiently as possible, without intermpting on-going DMS operations. Note, however, that these potential problems affect any DMS, regardless of how tightly it is integrated with the GIS.
Custom Application vs. Product
There is a danger that any application with multiple interfaces and site-specific data will become a custom solution that only works for a particular GIS data model, or in a particular client environment. Many of the currently available DMS solutions have fallen into this trap. Each new installation starts from the most recently completed version of the system, rather than are-usable base product. Implementing product upgrades becomes an increasing nightmare as more and more sites are brought on-line. rather than are-usable base product. Implementing product upgrades becomes an increasing nightmare as more and more sites are brought on-line.
An Architecture for Success
Between April and July 1997,two industry vendors and a using utility jointly conducted a technical proof-of-concept laboratory. The main goal of the laboratory was to ensure that all key fictional and performance requirements could be met by a new proposed GIS-based DMS architecture. A description of the laboratory approach and results follow.
Database Architecture
The basic database architecture used during the laboratory consisted of a read-only version of the GIS database and two linked partitions containing the DMS database, as portrayed in Figure 1. The DMS database was split into static and dynamic partitions in order to take advantage of the object-oriented database and spatial indexing schemes of the GIS, while still providing a short transaction repository for the dynamic DMS data.
The short transaction database used in the laboratory was Sybase, although recent testing has also used Oracle. This basic architecture was repeated at each separate dispatch site, as in Figure 2. Appropriate replication strategies are employed in this architecture to propagate data changes between sites. During the lab, we only tested the short transaction database replication, since replication was seen as a straightforward implementation. Although we only simulated two sites in the lab, extending this database architecture to additional sites presents no particular difficulties.
Figure 1. Basic Database Architecture
Hardware Configuration
During the lab, we started with a very simple test environment and then added components piece-by-piece until we reached the configuration shown in Figure 3. In addition to the database components discussed above, a CIS trouble call table was also present in the short transaction database. Trouble calls were inserted into this table at one of the sites by a simulation.
Figure 2. Multiple Dispatch Sites
tool called the “Trouble Call Playback” engine. These call records were replicated to all other sites via the short transaction replication. Each site also ran its own “trouble retriever” process. This process was responsible for retrieving trouble calls from the CIS and perform device prediction.
Figure 3- Final Hardware Configuration
Laboratory Results
Performance Testing
Three basic test scenarios were run on each hardware configuration used during the lab. A simulation tool generated these scenarios by modeling customer calls downstream of a set of failed devices. The tool allowed various parameter settings, such as the percentage of affected customers that actually call to report the outage and how long after the outage begins until they actually call. Another tool simulated dispatcher activities on the system by assigning crews to outages and cycling outages and crews through the outage restoration process.
Availability Testing
In order to test system availability in the event of a hardware or network failure, one of the Sybase servers was shut down while running a test. The second server was allowed to continue for some time, and then the fmt server was rebooted. The goal was to verifi that the second server continued to run with no problems when the fmt went down, and that re-synchronization occurred correctly and efficiently when the first server came back on line.
Results and Conclusions
After several weeks of setup and tuning, the team achieved roughly 8,000 trouble calls per hour through a single “trouble retriever” (including device prediction) during the laboratory. More recent tuning and testing indicates the potential of 25,000 calls per hour per retriever. Changing the interface so that the CIS pushes calls into the DMS, allowing the DMS to concentmte on device prediction, is expected to further improve call throughput. By nmning parallel retrievers (or prediction engines), throughput rates of over 100,000 calls per hour are attainable. The laboratory testing also simulated up to I dispatcher action every six seconds with no significant impact on the trouble call throughput rate.
The availability testing was also successful. One of the Sybase servers was shut down for a total of 18 minutes while the second server continued to operate. When the server was restarted, approximately 40 MB of data had to be replicated across the WAN from the second server. This re-synchronization took approximately 14 minutes. It is expected that improvement on this performance will be realized by using stored procedures to execute many of the bulk update activities (only the procedure invocation is replicated, rather than each individual data change).
Summary and Current Progress
In summaty, this paper presented the basic functionality and interfaces required of a Distribution Management System (DMS). It then explored the advantages and disadvantages of tightly integrating a DMS with a GIS. From these, it is easy to see the desirability of building a DMS product on top of a GIS. Results from a proof-of-concept laboratory go fhrther to show the feasibilityof this integration. Cost savings via shared technology and infrastructure investments, plus increased functionality and a robust, flexible development environment, make GIS the perfect choice for a DMS product platform. Note that the architecture presented in this paper does not strictly require that the GIS data reside a GIS proprietary database. With the advent of Open GIS and the incorporation of same into the GIS vendor offerings, data from any GIS database can be accessed and integrated with the DMS.
Previously, utilities expected to pay millions of dollars in licensing and implementation services for a custom DMS solution. These solutions were not tme products – upgrades were rare and difilcult to install. Maintaining consistent data in the DMS and GIS was a nearly impossible task. With this new approach, these same utilities can expect to pay less than half the cost of other systems to buy and install a DMS product. Such products should include regular, easy-to-install upgrades, dedicated technical supporL and considerable commonality with the GIS database, user interface, and support infrastructure.
Bibliography and Additional Reading
- Batty, P., 1997, Outagt#Distribution Management System (0/DAZS) Technical Laboratory Results, Smallworld Systems, Inc.
- Briody, L.P., 1997, Finding out when the lights go out, Information Technology for Utilities, Summer 1997, pp.41 -44.
- Reason, T., 1997, lntegratedsystems help utility weather deregulation, Maine’s storms, Information Technology for Utilities, Fall 1997, pp. 60-62.
- Sileo, T., 1997, Going Beyond GIS to DA4S, Smallworld 97 Symposium Proceedings.
- Steinmeyer, C. and Sileo,T., 1996, Smallworld as a Multi-User, Quasi-Real Time Emergency Dispatch System, Smallworld International Conference Proceedings 1996, pp. 223-232.
- Vollmar, D., 1997, Short Transaction Applications in Smallworld– Is it possible?, Smallworld International Conference Proceedings 1997, pp. 51-58.