Considerations for the Successful Integration of an electric distribution geospatial application
with other enterprise solutions
Karen Ball Intergraph Utilities & Communications Mailstop: LR23B2 241 Disk Drive Madison, Alabama 35758 Jim Hayes Sacramento Municipal Utility District Mailstop: A301 Sacramento, California 95819-4628 Abstract This presentation will use a case study of the Sacramento Municipal Utility District (SMUD) AM/FM/GIS system to discuss various aspects of system integration. Examples from SMUD’s Service Delivery Information Technology (SDIT) environment and its interface points with other applications will be used to support the discussion. Integrating geospatial applications with other enterprise systems can bring critical data from multiple sources to maximize benefits to an electric utility. However, integration can also involve tradeoffs as the individual components are being implemented. Decisions of core functionality vs. interoperability or complexity vs. usability must be made carefully to ensure the best overall solution. System integration impacts the geospatial application’s software lifecycle through all project phases – from definition to deployment and into support and maintenance. Looking beyond the technological aspects of the solution, integration impacts business processes and often drives organizational changes. The importance of people to the accomplishment of any integration attempt will be stressed. Team members should be knowledgeable in their areas of expertise, be able to communicate with others within the team, and remain constantly aware of the potential for interdependencies. The success level is increased if key individuals can make a longterm commitment to the integration effort. Benefits of system integration Collecting and maintaining facility data is costly. However, integration can increase the return on that data investment for many areas within the electric utility. The benefits of integrating a geospatial application with other software systems within the enterprise are many. Designers can have more centralized access to supporting information and can provide more complete and consistent information to crews. Integration of the geospatial application with enterprise resource planning (ERP) information can streamline financial, material and work management processes. Also, entry of facility data in the AM/FM/GIS system can automatically populate financial records. Planners have a more consistent and correct data source to use as a basis for analysis. They can pull data from the facility model and also from customer billing information to be analyzed by a single application. An integrated geospatial application can also provide a means for making others aware of long-term plans. Operations activities can benefit from shared geospatial information. Facility data collected and maintained in the GIS can be used as a basis for outage predictions and crew management. Brief overview of SMUD’S SDIT system The Sacramento Municipal Utility District (SMUD or the District) is in the midst of developing their Service Delivery Information Technology (SDIT) environment. SMUD’s SDIT system encompasses several major functional components. These include an AM/FM/GIS system to store and maintain geospatial facility data long-term, design and estimating tools to support job design, mobile data dispatch solution to communicate and manage field crews, electrical analysis functionality, and an outage management system. The SDIT system will integrate the components listed above and will also support interface points with numerous other sources and destinations of data. Landbase graphics and attribution will be imported from multiple outside sources. Existing hand-drawn maps are being converted for storage in the AM/FM/GIS system to then be used by the other components of the SDIT environment. Electrical load and customer characteristics will be derived from the customer information system, archived SCADA data and substation demand readings to support robust analysis. SMUD’s ERP system will provide information, updated periodically, to support job design and estimating. Information from individual facilities will be populated and updated in the ERP system as updates are made to the geospatial data. SMUD also has plans for more integration in areas such as document management. The system integration in progress at SMUD is expansive. When complete, access to geospatial data will be available at various levels. Designers, mappers, planners, and operations staff will be able to manipulate the data through specialized desktop applications tailored to their use of the data to accomplish their daily responsibilities. Others throughout the District will have viewing access to the geospatial data via the web. Thus, the geospatial data has the potential to support in many areas of the District’s business processes. Tradeoffs While system integration can provide many benefits, integration can also involve tradeoffs as the individual components are being implemented. Decisions of core functionality vs. interoperability or complexity vs. usability must be made carefully to ensure the best overall solution. Core Functionality vs. Interoperability From the onset of any initiative to pursue integration between two or more systems, the utility will be faced with decisions. Will the final solution include best-of-breed applications? That could result in looser coupling between applications. Will the optimal solution instead lean toward tighter integration? That may mean choosing applications that don’t provide the same level of functionality in specific areas but do provide a more seamless end-to-end presentation to the user. Such decisions are not black and white. The best answer will vary from utility to utility. When integrating with geospatial applications, visual display differences may have to be considered. AM/FM/GIS systems, design tools, outage management systems, and electrical analysis applications all present facility graphics. Consistent symbology across these applications will improve the usability of the overall solution. But since the intents of these applications differ, the information being conveyed by those graphics will differ. This may lead to the design of varying symbology. For example, it may be more important to be able to easily differentiate between open and closed devices when working with an outage management system in an operations environment than when designing a job for construction. Architectural differences between applications’ display engines may also affect symbology design. Options may be limited to the functionality that is common between a pair of functional components. SDIT’s GIS can minimize overlap of graphics in congested areas such as pad-mounted switchgears and substations by displaying smaller symbols and text on the geographic map based on characteristics of the facility data. The GIS also allows for the use of detail drawings, maintaining graphics for congested areas to be displayed in a separate window at a different scale. However, the design application only supports graphics in the geographic plane. Thus, detail drawings for switchgears in the SDIT environment were not a viable option. Some other areas that can vary between graphics engines include how line patterns and shape geometries are handled. Complexity vs. Usability A goal of system integration is to minimize the number of ways each type of data can enter the system. Having a single point of data entry minimizes the potential for variation in that data and helps maintain data integrity. However, there are often legitimate reasons in an integrated system for duplication of similar functionality. In the SDIT environment, the line design application will aid designers in completing overhead and underground power line designs. It is targeted for work in a radial (“openloop”) distribution environment, which represents the majority of SMUD’s residential and commercial distribution work. The design application provides standards and design assistance that are beneficial to the District’s day-to-day design work in these areas, but it does not provide the same level of design capability for network (“spot grid”) configurations. Therefore, similar data entry and edit functionality is duplicated in the GIS to support work in SMUD’s downtown area. Different business processes and enduser interaction will be required to accomplish design work in different parts SMUD’s territory. Impacts to application software lifecycle When a project involves integration of multiple systems, all phases of the application software lifecycle are affected. Define During the definition phase, business needs are clarified and interpreted into technical requirements of the new software system(s). These specifications must encompass core functionality of each application and interface behavior between new and existing applications. Processes are established during the definition phase that set the stage for all future phases. A team is built with representatives from multiple business functions within the utility and from different software vendors and possibly independent consultants. Each team member faces a learning curve to become more knowledgeable about other parts of the system and how those parts will interrelate. The output of this phase is a set of requirements documentation to support future phases’ activities. The team must share responsibility for the content of the requirements and must determine who has responsibility for the maintenance of the documentation at each interface point. Design During the design phase, the technical team must determine how the technical requirements will be met. Special attention must be paid to areas that affect more than one application. Since data are always exchanged when systems are integrated, the modeling of that data must be carefully considered. Representation of units for electrical characteristics may be different for design tool functionality and electrical analysis. Object relationship assumptions, such as how to represent multiple circuits in shared conduit, might differ between the design application and the GIS functionality. Such differences will need to be discussed and overcome to arrive at a data model that can support the integrated systems. Implement Once design is complete, the core areas of functionality must be implemented and introduced into the overall integrated system. The addition of each interface point introduces difficulties. Remote access may be needed to test against ERP and other systems already in place at the utility. Some parts of the overall system may be progressing along different project timelines, requiring careful coordination of changes and of resources. Deploy As the system is deployed, it introduces change within the organization. When the system being deployed is integrated with other systems, more people within the organization are affected. Software installation plans can become complicated. Training must encompass multiple systems and target different subsets of the total end-user community. Maintain/Support Once the system is in production, system integration affects maintenance and support activities. Before modifying any software within the integrated solution, the changes should be analyzed for potential impact to other parts of the system. Version upgrades must be coordinated to ensure functional compatibility. A continued knowledge of interdependencies is necessary even after initial project completion. Throughout System integration projects are often undertaken in separate overall phases. For example, the full design and implementation of electrical analysis functionality may be delayed until the design tools, GIS application, and data conversion are more complete. The simple waterfall software lifecycle model is influenced by the fact that different pieces are accomplished along different timelines. There are always interdependencies between the project phases. Even though effort should be made to minimize impacts to other parts of the system that are farther along the software lifecycle, such impacts will occur. Design of add-on functionality such as electrical analysis may uncover the need for a new data item to be captured, which would trickle up as a data model change affecting other parts of the system. Therefore, processes must allow for reiteration and introduction of late changes. Importance of people The contributions of individuals are crucial to the success of any integration attempt. As different software applications and utility functional units are pulled together, perspectives of multiple vendors and user communities must be considered. Subject matter experts must be knowledgeable of the area they represent and willing to understand others perspectives. Communication skills, informal and formal, are key. Decision-making often involves negotiation and give-and-take to arrive at the best overall solution. The dialog and tone of these discussions can influence the success of the endeavor as much as the resulting deliverable documentation. From beginning to end of the integration effort, the team should work toward common objectives with a shared commitment. That commitment must be made at the organizational and at the individual level. Staffing can at times become difficult. If the integration effort is proceeding in parallel phases, some overlap is desirable for increased awareness of interdependencies. Such overlap adds to scheduling complexities and can affect progress. The utility faces the strain of balancing the current day-to-day activities of employees with the time and effort spent investing in the future interest of the organization. Summary In short, with the benefits of system integration come some challenges to be met. Balance must be kept between the needs of the individual functional areas. Focus toward the ultimate goal must be maintained through multiple overlapping project phases. Software technology and defined processes to follow are important to provide necessary functionality and a framework within which people work. But software and processes can never accomplish system integration without effective use of the combined knowledge and commitment of people who believe in the advantages and reality of the final system. | ||
|
|