GIS/OMS project implemenation at peco energy, an exelon company
Valerie L. Carter Peco Energy 680 Ridge Pike Plymouth Meeting, PA 19462 Company background PECO Energy, an Exelon Company, is an established electric & gas utility with approximately 1.8 million customers. The company has operated in the Philadelphia, Pennsylvania region for over 100 years. PECO Energy has four dispatching offices for the electrical and gas, transmission and distribution systems. There is an office for each (gas and electric) of the transmission systems. One of the distribution offices handles secondary electrical calls and gas emergency calls. These calls are high voltage, wire downs, police and fire, single light out, carbon monoxide, etc. The other office is responsible for the electrical distribution system from the substation to the distribution transformer. Both distribution offices are in the same building. PECO Energy has three regional offices that primarily handle planned work activities. During large storms, one or more of the regional offices serve as local dispatching offices.
Project overview In September 1999, Hurricane Floyd hit our service territory effecting over 500,000 customers. Shortly after the restoration efforts were complete, PECO Energy formed a team to critique our storm response efforts. One of the items of the critique was the limitation of our existing mainframe system, the Trouble Management System (TMS). The existing system has been in service since the late 1970's. The operational functionality of TMS has degenerated over the years and updating capability is severely limited. Three separate files contain the connectivity information for customers, transformers and circuits. In January 2000, the project team received approval to implement a GIS-based, outage management system by December 2000. This paper covers some of the lessons learned by implementing a geographical information system (GIS) concurrent with an outage management system (OMS). In March 2000, PECO Energy selected Intergraph as the prime contractor. ASI, Analytical Surveys, Inc. is the subcontractor performing the data conversion work. The GIS uses ActiveFramme and OMS uses InService. PECO Energy also uses Microstation for the other mapping products. Our project focused on installing a new outage management system. Every decision point comes to the single question; is this function or piece of data required for OMS? The GIS model is sparsely populated; we converted only those devices required for OMS. We did not choose to do mobile data terminals (MDT), automatic vehicle tracking (AVL), work management interfaces, or GIS based design and estimating tools. Landbase selection A landbase is a mapping product that contains information regarding the geography of a specific area. Information can include street names (and aliases), political boundaries, and waterways. It may also include street range information for location by address. The decision to convert your existing landbase to a commercially available product is unique to each organization. You need to be able to answer the following questions:
GIS model development A GIS is a repository of information. The final application dictates the information gathered and stored. For example, if you are planning to manage assets with the system, then information like manufacturer, date purchased, installed, etc. is necessary. If you are planning to design from the system, then information like rating, voltage class, interruption rating, phase, status, type (oil breaker vs. SF6), etc. is required. To support the OMS, we needed a sparsely populated GIS database. We chose to only model the primary equipment and the premise (house meter location). However, you may need to capture additional equipment to support the selected items. As an example, to install an aerial transformer, one needs information about the structure that supports the transformer. In designing the GIS (for OMS), one also needs a very good understanding of how your particular system operates. The GIS application generally supports a breaker, transformer and switch. You may have breakers that operate differently. At PECO Energy, we have a 34kV distribution system that feeds 4kV unit substations. A unit substation is a transformer and rackable breaker integrated into one structure. Our GIS model needed two types of breakers to distinguish between the unit substation and the distribution substation. We also have a few breakers that we call line breakers. One side of the breaker is circuit 1 and the other side is circuit 2. PECO Energy extensively uses interposing transformers. These transformers step the voltage from one distribution level to another. We configured our GIS model to handle both types. Fuses and elbows are switching devices. You may have different symbology or different operating practices for each device. You need to ensure that the GIS model can accommodate all of them. For example, PECO has a combination, terminal pole symbol and a standard fuse symbol to identify a terminal pole fuse. We did not need to create a special device for the terminal pole fuse. We did, however, need to make changes to the standard product to cover switchgear and elbows. When you make changes to the standard product, you need to ensure that you document and thoroughly test the changes with converted data as well as new data (placement rules). To support the OMS migration development, we chose to do our testing of GIS in stages. The first test supported data and functionality required to support data conversion and OMS development. The second test focused on interfaces and changes to the program that did not impact data conversion. Legacy system interfaces There are no "short-cuts" in the area of interfaces. Regardless of what type of system is installed or what functionality is used, interfaces need to be completely developed. We had four major interfaces that PECO had to develop. They were new calls (CIS to OMS), query calls (CIS to OMS), completion information (OMS to CIS), and customerto- transformer information (CIS to GIS). The vendor developed the interface between GIS and OMS. The original customer-to-transformer (connectivity model) was a tabular, mainframe application. It was difficult to use, see errors in the data, and did not provide any data integrity with the printed circuit model. The premise reference number identifies the service location. They are created and deleted within CIS. Once daily, a printed report of premise changes is sent to the Mapping Group to update the tabular connectivity model. The new interface provides a graphical tool for the user to see the premise data, including street address, and the associated transformer. This interface will be activated when the entire GIS/OMS system is activated. The Customer Information System (CIS), and the existing Trouble Management System (TMS) are mainframe applications. An outage call is a data transaction from the CIS to TMS. To streamline the impact on the Customer Service organization, we chose to use the existing CIS outage call handling processes. The change from TMS to OMS will be transparent to the call takers. They will use the same input screen and query commands with TMS and OMS. The new call interface (CIS test region to OMS) will be activated in December 2000. By having this interface available early, we are able to provide on-the-job training to our dispatchers and other emergency response personnel before full operation with the new system. This will also provide us an opportunity to fine-tune some of our new business processes. The query call and completion interfaces will be completed in January 2001. The existing TMS provided summary information, number of customers affected, and type of work involved. We needed a replacement for this summary screen. We developed an intranet website to provide this functionality. This interface was not in the original project scope. OMS development One of our project objectives is to have an outage management system that is easily configurable and very little customization. The customization work involves the interfaces with the GIS circuit model and the Customer Information System (CIS). To get a jumpstart on understanding OMS functionality, we received a demonstration unit and a training system very early in the project cycle. The systems provided us an opportunity to become familiar with the general workstation layout, terminology, commands, and system functionality. Additionally, we were able to lay the groundwork for developing new business processes. We populated the training unit with our personnel information, vehicle data and other model data. When the rest of the system arrived, the data was transferred to the main OMS server. The training of the dispatchers and the emergency response personnel is scheduled to occur approximately two months before full system operation. Our business process and training team started meeting six months before full system operation. The primary purpose of these meetings was to develop the business process and associated training issues to support them. We elected to do GUI (graphical user interface) customization prior to training. Our goal was to have the dialog boxes look and feel in the final version as soon as possible. The system will be available for demonstration purposes approximately three months prior to full operation. This strategy deviated slightly from the vendor's recommendation. We scheduled the acceptance testing to be performed in stages. The interfaces will be tested and accepted as soon as they are available. Functionality testing we be done in several stages. The first stage contains detailed scripts of calls and expected system operations. We will perform this stage with a CIS simulator and the OMS software only. The second stage uses the same scripts but includes interface testing to the mainframe. Stress testing and disaster recovery testing will be done before full system operation. The same test scripts will be used for dispatcher training. Developing new business process provides the most cost savings. However, it is the most difficult task. With the exception of the project team, the understanding of the system capabilities is limited. We defined two major areas, resource management and reporting. For resource management, we examined what activities need to be performed to provide an accurate picture of the status of the workforce. The plan includes developing basic procedures for the dispatchers. Some of the actions will be new for the dispatchers. For example, in our current environment, each dispatcher keeps track of the field crews by writing it down. The new process has the dispatcher logging the crew status into the OMS. This enables the management team to have accurate status information of what crews are on system and who is on assignment. The other major business process area is accurate outage status information. This is broken into three areas, real-time, customer service, and after-the-fact analysis. For the real-time information, we plan to focus on streamlining the completion reporting process so that customer restoration information was accurate as possible. This enabled management and the Call Center to have more accurate data. In the current system, reporting related information can only be done when the job is completed. With the current system, outage statistics was inaccurate during large storms. Completion of reporting information was considered a low priority. With the new system, 90% of the information is captured as the job evolves. Things like dispatcher name, crew assigned, number of customers, etc are automatically recorded. The other 10% of the information is captured with an easy to use, GUI interface. Conclusion The single, most important lesson is communication among all involved parties. While we had meeting minutes and saved emails, many times there were misunderstandings. We, the project team, would walk away with an understanding of an issue and assume the other parties (the vendor, other business units, etc.) had the same understanding. Often, everyone gets accustomed to using the local jargon and commits to writing the bare essentials. When a document is reviewed months later, different interpretations arise. Within our organization, there was often confusion about what was coming with the new system, what parts of the old system would stay, etc. The best recommendation is to be as detailed as possible, confirm assumptions and communicate often. We are just beginning to see the benefits of the system and plan to capitalize on the functionality to improve customer satisfaction and system reliability. | ||||||||||||||||||||||||||||||||||||
|
|