Implementing AM/FM/GIS at an RUS Electric Cooperative
Dan C. Garman P.E. Aiken Electric Cooperative P.O. Box417 Aiken, SC 29802
Overview
The Rural Utility Service is a United States Department of Agriculture program to assist Cooperatively owned electric, telephone, and water utilities with loans, design standards, and quality assurance. Cooperatives are businesses owned by the members or users of the services the business provides. Electric utilities of this type range in size from two hundred to over one hundred thousand members. Aiken Electric Cooperative (AEC) has 35,000 active meters, making it a mid-sized RUS utility. The following advertisement may fit the search for the perfect AM/FM/GIS coordinator at a cooperative. Wanted: One GIS coordinator skilled in logical and physical database design, computer aided design, GPS fundamentals and equipment, GIS projection and mapping standards, budget creation and management, project coordination, workstation and server hardware and software, and local and wide area networking. Four-year engineering graduate preferred for additional duties to be assigned. There is very seldom one expert available in all the areas listed; therefore, one has to learn to adapt to the changing demands and make sound decisions using available information. The Internet becomes an invaluable tool in collecting the required background material. AEC is migrating from a paper system developed in 1959. This is a map/grid-based system that is employed at many cooperatives. The current map numbers are the basis for customer accounts and pole locations. The migration from a 40 year old unchanged system brings with it both cultural and political challenges. Management at AEC began researching the feasibility of replacing the existing system in 1996. The initial goals and budgets were derived with assistance from South Carolina’s state owned generation, transmission, and distribution utility, Santee Cooper. Santee Cooper has more than 15 years of electronic mapping experience, and along with the cooperatively owned G&T, Central Electric, provides generation and transmission services to 15 distribution cooperatives in South Carolina. The resulting project plan and budget was submitted to AEC’S board and the project received approval in 1997. AEC’S original project plan called for the selection of a national consulting group to act as a general contractor for the project. With the addition of the above noted GIS coordinator, AEC elected to act as its own prime contractor and to request proposals for each project phase. A new project plan was developed that separated the project into five sections. Briefly the sections are as follows:
An extensive self-analysis is the required first step leading into a project of this scope. Unfortunately, group brainstorming and team building techniques prevalent in many industrial settings have not been oflen introduced at rural cooperatives, and if performed it has generally not been at the staker and line foreman level. It is essential that these front line personnel be included in any beginning discussions and be continually consulted with during the project lifetime. This process will extract knowledge from those in the most day to day contact with operations and create a buy-in where the personnel who can alter the long term success of the project feel some ownership with the project. AEC felt strongly that suggestions offered by all personnel be considered and a response provided if a suggestion was rejected or could not be incorporated. This is not to diminish the contributions from supervisors and management. Once a healthy flow of information is initiated, it is critical to collect, contain, and organize all the information into one or several documents to create the foundation of all future process steps. AEC elected to create two documents for the bulk of this information: First, the Internal Functional Requirements Document (IFRD), and second, Internal Database Design Document (IDDD). The IFRD contained many sections including basic requested functionality, modeled workflow, identified interfaces, hardware and network requirements, and OS and GUI requirements. The IDDD contained objects and attributes, selection lists for attributes, default values, if any, and other items typical of a rule base. It was not AEC’S intent to create data models within the IDDD, just to collect the information in the most efficient way for the cooperative. AEC considers these documents to be living and has updated and extended these throughout the life of the project. They were the primary documents referenced for the vendor selection process, the field inventory request for proposals, and the design of various interfaces. Compare Existing System Models AEC felt that it could use the expertise of a national consulting firm to compare its requirements as outlined in the IFRD and IDDD with the standard data model and functionality offered from the major AM/FM/GIS vendors. AEC also believed that it was imperative that as little customization as possible be required from the selected system. (Highly customized systems are very hard to maintain, even for a long term dedicated staff. Upgrades are much more challenging and costly, and developed interfaces sometimes require modifications to function properly.) AEC utilized a consulting firm to aid the search for appropriate systems for consideration and to gather the latest, and often unpublished, details of importance for the comparisons. AEC discovered that it had more knowledge about the existence of co-op oriented software and worked with the consultant to ensure inclusion of major and minor systems within this project phase. Included here is a short list of the questions and issues addressed during system comparisons. How well does the base product fit AEC’S requirements? What is the amount of modification required to meet those requirements? Are CASE tools available for rule base modifications? What optional packages are currently available? (Field maps and design, electrical analysis, outage analysis, customer and work order interface tools) Are the vendors incorporating new technologies as they emerge from the core SW providers? What are the DBMS and coordinate data storage requirements? (HW and SW) What are the HW and SW requirements for various types of clients? What are plotting and reporting capabilities? AEC did not ask for a selection from the consultant, only a pro/con analysis from a short list of candidates. It also requested the option of utilizing the consultant to create an RFP for the application vendor and modifying the core model to meet additional requirements, but eventually elected not to use the consultant for those options. The actual system selection may have been the most challenging part of the project. Three finalists were brought to AEC for a system review. A review of the vendor’s core functionality was covered with the same front line personnel noted above. Additional suggestions and functionality that arose during these sessions were noted and included in the IDDD and IFRD. AEC was also migrating to a new customer information, work order, and accounting system and merged the timing of the GIS system selection with that decision. AEC was unwilling to create a blind selection matrix, and so, after entering the numbers let the matrix decided the future. The belief was that there was a “right” system for Aiken and atler many hours of discussion and meditation (tea leaves optional) the selection was made. Essentially, the choice was for a system with better core technology or a system that functionally matched AEC’S needs. AEC came to the conclusion that the more co-op friendly system was the better choice. Unfortunately, one cannot have everything. Even though the “best fit” system was selected, there were still functionality gaps. A list of these missing functions was collected and prioritized as critical, preferred, and future. It is important to work with the application vendor or other developer to address the critical list as soon as possible. One must remain open minded that if a perceived critical function will compromise the integrity of the vendor’s system, one must reevaluate its status and possibly find an alternative solution. If the function is essential, recognize that harm may be done to the core system down the road. Refine Field Inventory Requirements AEC believed that a field collection effort could not begin without a final selection of an application vendor, and therefore, finalized data structures. Within field inventory, data collection progressed at the site in the form of RUS construction standards. This requirement focused AEC’S vendor search on those companies with staff familiar with such standards. In addition, AEC required the collection of a GPS coordinate for each structure, and that an accurate circuit model be delivered in the application sotlware’s format. Paths for underground wire were determined from existing paper maps. In order to facilitate this process, a scan of existing maps was performed and a cross-reference grid was built between the new and old map-block layouts. Matching existing maps to the new state plane map grid proved to be a challenge because no coordinate system was used in creating the initial system in 1959. It was expected to use these scanned images to provide a interim electronic field data solution during the two year inventory project. The AEC service territory covers approximately two thousand square miles within nine counties in mid/western South Carolina. Existing land base data from the various political entities was aged at best and non-existent at worst. AEC elected to have its area flown and a four hundred foot scale map was generated in ortho photo and vector format. An additional task of the field inventory provider was to incorporate AEC vector data within the target system. This process was made simpler because of the shared coordinate systems. The field inventory vendor was also called upon to coordinate minor initial data structure modifications to incorporate field inventory requirements. Similarly, minor symbol set changes from the base model were coordinated by this vendor. AEC required the application vendor to sign off on all changes to the base system to ensure existing interfaces and extensions, such as automated trouble call analysis, would not be compromised. AEC is currently in the process of performing quality assurance testing on delivered data. It has identified but not fully worked out the process for several critical data conversion issues. For example, it must merge multiple deliverables within the same geographic areas where the first deliverable may have been modified. It must ensure that field staking and construction done in a previously field inventoried area gets properly incorporated into the new system. And it must keep alert to any opportunities for unacceptable inaccuracies to become injected into the final product. Acquire hardware and software and Enhance corporate infrastructure As a part of the IFRD, AEC separated client hardware requirements into several classes. On the low end was a viewer PC that would be located at a customer service representative’s desk and able to locate and view spatial system data. Engineering personnel coordinated with the information technology department to ensure conformity within hardware purchases. Other classes of workstations included a spatial query specification and a field viewer laptop. On the high end was specified a GIS workstation whose OS would be dependent on the system purchases. AEC is able to use standard Microsoft operating systems across the board; thus it expects, because of this uniformity, to have a smaller learning curve from a viewer workstation to the AM/FM/GIS server. AEC elected to purchase a server with redundant features to minimize downtime. Uninteruptable power supplies were installed on all workstations that process transactions against the master database to avoid corruption. AEC purchased all its system hardware from a common vendor with extended on site warranties in order to enhance maintainability. A major challenge facing AEC was the proper usage and limitations of internal local and wide area networks. The main otice was in an enviable position for many cooperatives with 30 PCs connected with CAT 5 wiring to a central hub. However, even with the primary network applications being terminal emulators and mail clients, it utilized most of its network bandwidth without AM/FM/GIS in production. The expectation is that AEC will have to upgrade its hub to a level two switch to gain additional bandwidth and may also need to convert selected servers and client to 100baseT connections. AEC’S district offices presented a greater challenge due to their sharing of a point to point channelized TI with the interconnected phone system and various small wide area data needs. The effects of the limited wide area bandwidth will not be known until deployment of software in those areas. if system performance is unacceptably slow, there are several options including installing a higher bandwidth data path and some type of local cashing of relevant data at the local site. This adds to the complexity of a required update/verification cycle at night or on weekends. Roll-out Training Program and Software Scheduling training time is a painful issue that faces all project managers, and AEC is not immune. AEC cannot schedule a training class for a week at a time with all five stakers. A class size less than five is very inefficient on site and it is time-consuming and expensive to send employees one at a time to training classes offsite. Employees may require two or three weeks of training to become adept on all the new software, AEC has elected to initially focus on the primary staking application and gradually cross train everyone on the more core mapping and GIS components. It will also utilize local technical schools for any basic operating system or computer aided design classes. The expectation is that within six months ail three district offices will be designing jobs on the new system and that AEC will have two to three key users intimately knowledgeable about mapping and GIS functions. The introduction of a new work order system at the same time as the mapping project has brought about benefits and opportunities. The stakers were required to learn the data entry process on the new work order system without any computer design involvement. Then the inside office staking application, which creates work orders on the billing and accounting system, was added. As a third phase, a GPS based field design module will be deployed that will interface with the inside staking process. By implementing this one step at a time, more time is allotted to deal with the problems from each individual phase. Additionally, if the staking application is down for an extended time, the work order process can continue through manual entry. AEC has made a commitment to purchase corporate systems that have existing interfaces between them whenever possible. Systems that it plans on incorporating include Interactive Voice Response (IVR) system, Trouble Call Analysis (TCA) system, Automated Meter Reading (AMR), and Voice Over 1P(VOI) integration. Each of these systems may have integration benefits and must be reviewed closely for inclusion into the existing corporate projects. We must be aggressive in our view of the future, but not bind or blind ourselves with complexity. Review With focus and active interest, AEC has come a long way in a short time toward incorporating a new mapping system. However, time frames are tricky entities, and no one at a cooperative is allowed to wear just one hat. If the coordinator has the background to manage the issues identified, it is highly likely that they will be drawn into additional technology based tasks. It is prudent to anticipate that some or all project phases may require “elasticity” at best, or “take more time” at worst, than initially forecast. This is not necessarily a negative finding; on the contrary the positive side effects of permitting more time and interaction for input from staff and facilitating understanding of the cooperative way of business is a true bonus perk. | ||
|
|