Integration Models for GIS Based Network Simulation and Analysis

Integration Models for GIS Based Network Simulation and Analysis

Larry Trussell
PhD E.E
Lead Development Engineer
Jeff Kenney
Manager - Business Development
Advantica Stoner
PO Box 86, Carlisle PA 17013
larry.trussell@advanticastoner.com

Abstract

Utilities with centralized GIS are now looking to further expand their competitive advantage. A clear step ahead is to enable distribution system simulation and engineering analysis from within the GIS. In the past, data was extracted from the GIS. Missing data was supplemented. Validation and data checking routines were invoked. Finally, the data was brought into an engineering analysis product and analyzed by an engineer.

his approach moved data from the GIS to the engineer's desktop. It enabled the engineer to do his job more effectively. However, knowledge sharing is invaluable. And there is a clear advantage to enabling more utility workers to invoke distribution analysis on a common set of data. Running a load-flow analysis, inventory analysis, reliability, customer outage prediction, or an economic analysis directly from within the GIS has tremendous value.

Engineers, technicians, managers, and executives throughout the company can share the results from these applications. Results can be very detailed for those interested in details or very general for those interested in the larger picture. Regardless of the way that results are presented or "published", GIS based simulation and analysis is consistent. The analysis is based on the shared corporate data of the utility. The data is acceptably current and correct.

The GIS is part of the core of most of today's utilities. It is the key to the competitiveness of these utilities in the future. Understanding of the value of being able to tie critical data together through a GIS has been a motivator for utilities. Understanding the efficiency to be gained by sharing the most fundamental sorts of data throughout the utility and using that data to bind and manage new sorts of data has led companies ahead.

The Challenge of Simulating with GIS Data

The GIS serves as the central hub for detailed granular data for large systems. Modern engineering analysis packages run off of detailed granular data for large systems. Hence it seems that engineering analysis should be available directly from the GIS. There are challenges with this but more engineering analysis applications are available from many GIS systems. Basic tracing, load analysis, and capacity studies are available for the GIS. Fault and load-flow analysis are also available but are run on a simplified model. The problem that will be discussed in the remainder of this paper is that GIS data and engineering analysis data are not wholly compatible. A number of solutions for coupling engineering analysis to GIS data will be given. In each case, a process for data management and validation must exist. That process is outlined later in this paper. First, lets look further into the challenges and the justifications for engineering analysis within the GIS.

Utilities must become more competitive. They are required to supply more power at a higher quality and greater level of reliability with fewer planning engineers. The GIS is an enabling technology to move utilities ahead. Millions of dollars and hours are invested in GIS implementation. Once the efforts have resulted in mature data sets, software, and processes, it makes sense to leverage engineering analysis. Why should engineering analysis rely on separate data sets? The GIS is a master data repository, it has corporate support, and a formal it has corporate support and a formal process manages it.Shouldn't engineering analysis data be a subset of GIS data? If information can be visualized in an engineering analysis package, couldn't it be visualized in a GIS?

The answer to these questions is "Sort of." Certainly engineers and information technicians do not want redundant data. Data should come from the GIS and any changes related to facilities, customers, or system operations should be reflected in the GIS. It is true that an engineering model can be built from GIS data. In nearly every case, however, the process is not simple and it is not direct. The GIS "network model" is substantially different than a "network model" used for engineering analysis.

For example, information about fuse holders, fuse barrels and fuse links may be listed in the GIS. The amp rating and time/current characteristics of the fuse may be the only piece required for engineering analysis but information about the holder, barrel and link must be collected so that the electrical connectivity between the fuse and its associated line section can be determined. This is not a trivial exercise in many cases.

The GIS contains information that is not electrically relevant to analysis. The type of connectors used on each elbow phase within a cabinet probably does not impact most types of electrical analysis. The connectors could, however, be central in tracing the electrical connectivity of the system. This is even the case with basic line or cable sections. Lines best represented in the thousands of feet in analysis software may be broken up into segments of hundreds of feet in the GIS. Poles, guys, arrestors, and other hardware may play a role in the GIS connectivity while having no place in engineering analysis.

This leads to nodes. Nodes in a GIS are oftentimes spatial intersection points. Poles, guys, cross arms may all share nodes. A 34 kV line and a 12 kV line intersecting on a pole may share a "node" within the GIS. In the engineering analysis context, nodes represent electrical connectivity points. Obviously 12 and 34kV lines cannot share an electrical node.

All of these issues are not necessarily problems. They are conflicts resulting from environments focused on different aspects of the distribution system. The GIS is focused on tracking and managing the facilities and assets making up the distribution system. The analysis software is focused on a reasonable model for representing the electrical behavior of the system. The electrical model is "reduced" from the tremendously granular GIS model so that every component has some electrical analysis significance. Even an electrical system modeled at a pole-to-pole level must undergo substantial reduction. The electrical model must also be electrically connected. A pad-mounted switchgear may be made of dozens of components within the GIS but it may be a simple tie within the electrical analysis model.

The data quality focus is different in a GIS and analysis environment. Serial numbers for transformers may be tagged as critical data in the GIS while impedance data may not even be required. Many parameters that have a significant impact on voltage and loading levels in analysis may be loosely monitored in the GIS management process. These data issues and the differences in "networks" drive the five parts of the model building process listed in the next section.

Requirements for Generating Models From GIS

A GIS system is the key to a huge data system that is used by a diverse set of utility personnel and drives many areas of the operation of the utility. As was mentioned above, engineering analysis is most demanding of quality data. Furthermore, it hinges off of a small part of data that is typically stored in a GIS and may require data that is not stored in a GIS. Any ?solution? that results in engineering analysis directly or indirectly from GIS data must have implementations addressing the following five areas.

Tracing
The GIS contains millions of pieces of data associated with a utilities service area. Engineering analysis is typically needed for a feeder or substation. This data set is a very small fraction of the GIS data set. However, finding a piece of the feeder and then following the connectivity rules of the GIS to gather the complete feeder is complicated. Once the topology is found and connectivity is traced, data necessary for engineering analysis must be found through the normalization and referential integrity rules of the GIS.

Rules for topology, connectivity, normalization, and referential integrity are usually implementation specific. These rules are often put into place in an effort concentrating on mapping and facilities management. At the time of the rule implementation, engineering analysis is often not a consideration. This leads to the navigation of what seems to be foreign and convoluted rules when engineering analysis data extraction efforts are begun.

Conversion
Finding the data needed for engineering analysis is the first step. Next, the data needs to be converted. Unit and nameplate conversions are straightforward. Complications usually arise in topology and connectivity conversion.

Engineering analysis is invoked on models of nodes and the node connecting branches. Nodes are points of known or calculated voltage and branches are paths for current flow. Some GIS packages do not use branch and node concepts. Others support different types of ?simple? and ?complex branches and nodes or junctions. Representations can be very different because the GIS is a platform for spatial data and facilities representation and management. It is not a platform designed for representing electrical analysis quantities.

Some GIS models allow branch (or edge) intersection at non-nodal points. Generating nodes when necessary and forming the electrical topology is necessary to properly represent the system. Some GIS models require nodes on all devices. However, some engineering analysis tools do not require nodes on devices. In these cases, elimination of nodes may be necessary. Mapping overhead and pad-mounted switch models between a GIS and an engineering analysis model can be complex. Electrical topology is not usually managed within a GIS. A single node in the GIS often represents a pad-mounted switch. Determining the electrical path and network for these pad-mounted switches must be performed in a reliable manner.

Issues with feeder location, customer and load placement, line construction and many other aspects must also be resolved. Furthermore, if engineering analysis results are desired from within the GIS, results must be converted from the engineering model back to the GIS model

Validation
Most engineering simulation and analysis engines support robust data validation within the context of their use. Unfortunately, errors and anomalies showing up in the analysis are difficult to track back to problems in particular data coming from the GIS. For example, a line that is 30,000 feet long instead of 300 feet may result in bad voltages or failure to converge in load-flow analysis within the simulation engine. There are many problems that could cause a failure to converge problem. Associating the problem with an invalid line length could be time consuming. Data validation rules that are in place during the data tracing and conversion phases are essential. Having a length limit of 1000 feet would pinpoint the problem during the tracing and conversion process. The problem would be flagged within the context of the GIS where the problem could be directly investigated and possibly repaired.

Supplementation
A GIS typically supports data that is sufficient to specify the topology, connectivity, and construction of a power system. Detailed modeling parameters about devices, loads, and conductors are usually not stored within the GIS. This missing data must be supplied in order to perform engineering analysis and simulation.

Data supplementation should occur during the model tracing and conversion phase so that a complete data set is available for sophisticated data validation. Supplementation should be implemented with a rule based system so that defaults for modeling parameters can be based on line construction, phasing, location, or other GIS based constructs. Supplemental data may include source impedances, settings, demands or other information.

Execution
The goal of GIS based simulation and analysis is to generate and publish valid results within the context of the GIS. In some cases, the generation of analysis results is done from within an engineering analysis package. In these cases, the engineer is in command of executing the proper analysis. In other cases, it is desired to have engineering analysis invoked from the GIS. In those cases, a method for commanding the engineering analysis from the GIS must be developed so that the proper analysis is performed with the proper settings.

There are four reasons that engineering analysis from within the GIS is a very real and practical solution for many utilities.

Modern componentization

GIS advancement

Data interchange technologies

Standard reporting methods

Capabilities of today's software components and GIS products allow many solutions for enabling engineering analysis from the GIS. In all cases, the implementation requires objectives, planning, and a methodology [1]. Engineering analysis places extreme demands on data quality and consistency. It is acceptable to have sloppy analysis data within the GIS but there must be some process to identify problems before analysis results are rendered.

Sophisticated products integrate directly into the GIS. The distribution system model used by these components can be built from the memory and database objects within the GIS. In some cases, the analysis can be performed directly from these GIS objects. Results can be routed back into the GIS. Spatial queries tying analysis results to other GIS entities can be performed. Numerical results, feeder boundaries, or thematic maps can be generated. Modern data management technologies allow the supplementation of missing GIS data. Topology can be traced and data can be gathered quickly. The GIS with an integrated analysis component operates as one single program. The environment is simple and stable.

There are naturally many variations for enabling engineering analysis from the GIS. The particular solution setup by a utility depends on their engineering planning and operations philosophy, their legacy systems, their GIS, and their resources. A utility that depends very heavily on detailed multi-year planning studies may desire a solution that separates the GIS and engineering analysis environments so that engineers can have more flexibility with ?what-if? studies. Utilities interested in real-time operational support from engineering analysis may tend toward a web-based solution tied closely to the GIS and SCADA systems. There are many variations of solutions and some basic outlines are listed in the next section.

GIS Based Simulation Solutions There are countless variations for delivering engineering analysis and simulation from within a GIS. The age and technology of the GIS and of the analysis package lead to variations. The networking and database technologies used also contribute along with the desires, priorities, and timetables of utilities.

The architecture will fall into one of seven major categories of implementation regardless of how the system is organized and built. This section will review those categories.

Solution 1: Extraction
Extraction is the classic approach to integrating engineering analysis within the GIS. GIS data is simply collected and put into an external database. An external power distribution analysis package reads the data and is used by the engineer for detailed analysis. Here is a diagram representing the process:

Figure 1-Extraction architecture

This approach has advantages. First, extraction implementations have a long history and the technology is mature from both the GIS and power engineering analysis end. Second, engineering analysis can be performed off-line or outside of the GIS environment. This may give engineers more flexibility. Next, engineers performing engineering analysis do not have to be familiar with GIS. Information technology technicians can manage the extraction process to provide models. Finally, the engineer has full control. Since the model is stored external to the GIS, the engineer can significantly modify the model.

There are disadvantages with this approach. A paramount problem is that it violates the philosophy of many utilities to promote a single GIS database. External ?modeling? databases tend to proliferate. Another problem is that changes or corrections made by engineers in the model database tend not to get reflected in the GIS. An engineer might make a correction needed to perform his task. If that correction is not made in the GIS, he and other engineers will stumble across it again and again. A final problem is that this approach tends to be maintenance intensive. Personnel in the GIS, IT, and engineering groups have to collaborate in order to maintain this process.

Solution 2: Embedded Engine
In this case, the engineering analysis engine is called right from within the GIS. Results from the analysis are displayed in the GIS. If the engine uses COM technology, all data management is done in memory. No separate databases are created. Here is a diagram:

Figure 2-The embedded engine

A primary advantage of this approach is the seamless integration. This tends to simplify things for the user. An engineer can just request ?voltages? from the GIS and not be concerned about by-phase load-flow and settings. Even non-engineers can invoke sophisticated engineering analysis and utilize the results.

A drawback is the lack of flexibility. A broad range of engineering applications, features, and options within the analytical engine is useless unless they are exposed from within the GIS. Custom GIS application may be beyond the desire or capability of many utilities. Another problem may be that by insulating engineers from the details of the analysis and applications, serious analysis problems can occur and be unnoticed. An engineer requesting voltages from the GIS may get voltages generated from any one of many different types of load-flow. The results may come from a motor start analysis or a harmonic or fault analysis. If the voltages at the particular area being studied by the engineer are not noticeably peculiar, the engineer may not know if the right type of analysis was used to generate them.

Solution 3: Server Side Engine
As discussed previously in this paper, model tracing and conversion is a very complex operation. The operation also stresses the GIS and database. It may therefore be time consuming.

Server side solutions may be implemented to reduce tracing and conversion by moving the operations from each seat of the GIS to the server. Tracing and conversion of engineering models and standard engineering analysis are run on the server at periodic intervals. Results are populated back into the GIS.

Engineers can view current and power flows and voltages on the system in the state represented within the GIS. Here is a diagram:

Figure 3 Server side engine

The primary advantage to this approach is its simplicity, predictability, and low overhead. All software and databases are maintained on a single server. Obviously the limitation with this approach is the lack of flexibility. Modifications can be made to the architecture to allow client side modifications to be made to the model with a regeneration of results.

Solution 4: Server Side Publisher
This approach again isolates tracing and conversion to the server. In this case, however, a server side database is created with the extracted model. An instance of the model is associated with a client through an ASP session.

Figure 4 Server side publishing

In effect, the GIS is used as a navigator. Analysis is invoked through the client and takes place on the server. Results are published on the client.

The advantage of this approach is that all software and databases are kept on the server. A simple browser and a hook into the GIS is all that is necessary for the client.

Solution 5: Standard XML Files
There are a number of standardized XML formats or initiatives to create new standards to support distribution system data and results [2,3]. These efforts allow software within the GIS to extract distribution system models. These models, in XML format, can then be passed or streamed to engineering applications or other applications:

Figure 5 XML Integration

It should be noted that there might be inconsistencies between the modeling concepts and assumptions of the extractor within the GIS and the analysis software. Data validation and data supplementation must be performed on the XML model before proceeding with analysis.

Solution 6: Incremental updating
A sophisticated approach is to update a pre-generated engineering model with changes (or deltas) incurred in the GIS.

Figure 6 Tracking GIS Changes

As lines and cables are added of modified in the GIS, changes are passed over to a validated model within the engineering analysis environment. Provisions must naturally be made to assure consistency between a change in the GIS and a change in the analysis model. For example, an elbow could be deleted in the GIS. This may or may not result in a deleted item in the electrical model. It may result in no change or it may result in a topological change. This type of solution is complex to implement but it does minimize the overhead of model building. If GIS data sets are stable, this approach can be attractive.

Solution 7: GIS native analysis
Engineering analysis has been developed natively within the GIS.

Figure 7 Native Anlasis

Although sometimes successful, many problems usually inhibit this approach. First, engineering analysis needs a focused and model oriented platform. As we have discussed, GIS is designed for many things and engineering analysis is not usually one of the key applications. Modern analysis and simulation of power distribution systems requires extensive detail. Generating the algorithms to handle these details requires a substantial effort. Building such monumental software within the GIS proves to be too complex.

Engineering analysis needs to be consistent within a utility. A GIS native load-flow analysis will probably generate results inconsistent with a commercial desktop package or commercial analysis engine. Finally, GIS native analysis lacks the flexibility to grow and change with the power system analysis needs of the utility.

Conclusion

The role of the GIS at utilities is growing and we will continue to witness innovative applications of embedded engineering components within them. Utilities have mature processes based on their centralized GIS systems. They have well defined, heavily managed, reliable, and secure data. Understanding of the efficiency to be gained by sharing the most fundamental sorts of data throughout the utility and using that data to bind and manage corporate decisions has led companies ahead.

There is a clear advantage to enabling more utility workers to invoke distribution analysis on a common set of data. Engineers, technicians, managers, and executives throughout the company can share the results from these applications. Results can be very detailed for those interested in details or very general for those interested in the larger picture. Regardless of the way that results are presented or ?published?, GIS based simulation and analysis is consistent. The analysis is based on the shared corporate data of the utility. The data is acceptably current and correct.

The challenges of supplying reliable and high quality power at an affordable price require collaboration among many groups in a modern utility. It has been clear for decades that these groups require the use of similar data. The acknowledgement of the efficiency and necessity of data sharing within a utility has brought massive change. This change has been fueled by information technology and the fact that spatial relationships, presented by the geographic information system (GIS), form the backbone for data management and distribution system analysis.

References

[1] L. Trussell, Essential Software Development Methodology,? IEEE Winter Meeting, January 1999.
[2] EPRI CIM Extensions for Electrical Distribution and Asset Modeling?, http://standards.ces.com/cim/index.html
NRECA's MultiSpeak Alliance, http://technet.nreca.org/tdcoms/MultiSpeak_Long%20Version_072001.ppt