Gas Compliance/Maintenance Process Improvement Utilizing GIS
Wayne Meyer
In October of 1998, the gas portion of SCE&G was in need of a new system to handle all of the facilities covered under DOT 192. The program that handled the maintenance of all facilities was an old VSAM mainframe system. The problem was that all of these activities involved multiple date calculations for maintenance scheduling and therefore the program was deemed non-compliant for Y2K. This opportunity not only enabled an update of the programming but also allowed for the examination of different practices that had evolved over the years in the different divisions. A standardized plan was then developed that would improve efficiencies at a time when everyone was being asked
to do more with less.
South Carolina Electric & Gas 440 Knox Abbott Drive Suite 550 Cayce, SC USA 29033 The problem was attacked on two separate levels. The first level involved developing a new database and programs to handle the storage and maintenance of the compliance information. The second was to examine the field practices currently being used to perform maintenance. The main focus of this presentation is the field practices. Valve Maintenance Valve maintenance was the first process examined. It was believed that it would be easier to re-engineer the process if it was understood first-hand how the field personnel performed their jobs. Everyone in the GIS department was required to spend time in the field turning and maintaining valves, and it was an eye-opening experience. There had been suggestions from the field that too much time was spent driving from valve to valve. After spending some time riding with them, the GIS staff understood what they meant. Most everyone agreed that the process could be improved but no one was really sure where to start. It had taken almost fourteen months to correct the differences between GIS and the mainframe database. When it was finished there was a one to one relationship between mainframe maintenance data and the valves in GIS as well an increased mutual understanding between field and programming personnel. This procedure became the foundation for the new maintenance system. The valves were plotted by the last date operated to provide a visual depiction of the geographic distribution of valves being maintained each month. Some offices had sorted the valves by gridsheet so there was a north/south pattern, whereas other offices compiled the gridsheets in a more random manner. Sorting the valves by gridsheet was a quick and dirty way to at least provide some order in the absence of a spatial tool such as GIS. With GIS, significant improvements could be made. It was decided to focus on the largest division as a pilot, and less than two months were available to solve the problem and implement the solution. A new maintenance schedule was needed before the start of the next year. The first step was to summarize the number of valves by gridsheet and overlay this on the roads, pipes, valves and gridsheets. This allowed the local supervisor to look at both the number of valves and their relative location on the landbase. At this time there was little concern with the actual month the valves were currently being maintained. It was decided that all valves should be completed during the first ten months of the year. Our “pilot” division had 3,286 valves. Therefore, maintaining roughly the same number each month would yield an average workload of 320 valves per month. It was estimated that the new system should allow a worker to turn a minimum of 30 valves a day and only require the first two weeks each month to complete the work. This would leave the last two weeks to take care of any problems that were found during the maintenance. Ten new zones were created using the valve plots. Now a new month had to be assigned to each zone. An analysis was performed to determine the predominant maintenance month for each of the new zones. It was known from the start that this would be a two-year process to get all of the zones synched up. The latest allowable maintenance date (annually, not to exceed 14months*) was calculated for each valve in a zone and compared to the assigned month for that zone. Some valves had to be turned later the first year so they would fall within the correct month the following year. Some valves needed to be turned twice the first year to stay within compliance. Once the valves had been assigned to a new month based on geographic area, a suggested route for maintaining the valves was created. It was discovered during our field work that the technicians visited the valves in the exact order they were printed out on the maintenance sheet. Using the routing algorithms in GIS, the shortest path required to visit all the valves in each zone was determined. The new database was given an order variable and the new printouts were sorted and printed with the new suggested order. The local technician was given the opportunity to suggest a new route as field conditions dictated. After refining the process in pilot area it was implemented in all areas except one. One area’s office decided it was too late in the year to make anymore changes and asked if they could be allowed to delay their implementation until the next year. The benefits of the new system were seen in the first month. The field technicians turned a record number of valves in the first two weeks. Originally, it was thought that each person in the field could complete 25-30 valves per day, but they were completing 50+ on a good day. This freed up a significant number of man-hours for other maintenance work. Cathodic Protection Cathodic protection (CP) was a different animal. Our initial data conversion included all testpoints and rectifiers found on the source maps. However, there was no guarantee that they were in the correct location or that they still existed. The rectifiers were placed as points on the map. They were not associated to any specific pipe or CP system. All valves and insulators were considered bonded since our source maps did not contain any system specific information. As a result, individual CP systems were not converted. The first step in figuring out the extent of each system was to identify individual rectifiers and the break points that corresponded to that system. Each impressed current system was assigned a rectifier and traced to identify all steel pipe that was protected by that rectifier. These were the first CP maps ever produced by drafting. Previously, the CP technicians had taped gridsheets together and highlighted the steel pipe with a magic marker. These initial system maps were sent to the CP technicians for verification of protected steel pipe. It took almost six months for the technicians to finish this first round of clean-up and send the maps back to the GIS department. After completing the impressed current systems, attention was focused on the anode systems. These were much worse than the rectifier systems as the records for anode systems were in bad shape in most offices. It was decided it would be easier to run an analysis on all steel pipe to locate any pipe not contained in a rectifier or known anode system. Maps were created showing all “unprotected” steel pipe. The maps were sent to each division for correction. The local technicians checked each map for database as well as field errors. Most of the pipe thought to be unprotected was actually protected by an anode that had never been added to the old mainframe database. Also found were several pieces of steel that appeared to be isolated but were connect to an existing system by a long piece of tracer wire. Finally, there were a few pieces of pipe that were completely unprotected. The ultimate result from this phase was that there is now a high degree of confidence that all steel mains are protected by an impressed current or galvanic system. The next phase proved to be even more difficult. As previously mentioned, all testpoints that appeared on the source maps were converted without any quality control. The original project plan called for the converted testpoints to be evaluated and used as the base layer for the CP system. Within days of attempting to resolve the differences between the mainframe database and the mapped testpoints, it was decided to start from scratch. The list of testpoints that were currently being read was sent to the local technicians along with a new GIS-generated CP map. They were instructed to place the testpoints and ID numbers on the map exactly where they were located. The old testpoint dataset was kept by making it a background layer that could be used for future reference. When all systems were completed there was a one to one relationship between a GIS testpoint and its maintenance record. This process took an additional six months. The final step in the CP process was to create a new viewing tool that would allow the technicians to view each system by name and show its testpoints as well as the rectifier or anode. This process was a breakthrough in that previously it had not been possible to look at CP in this manner. The application was distributed to the field and each technician was asked to evaluate the placement and distribution of testpoints. New testpoints were added to provide complete coverage and some testpoints that were deemed redundant or unnecessary were taken off the maintenance schedule. After reviewing each system with the Manager of Engineering, the systems were checked off as complete. The tool was later enhanced to include all insulators and breakpoints between systems. This enhancement allowed the technicians to spot insulators that had potential to create problems and ensure adequate testpoints are in place to monitor them. The southern division took the analysis one level higher by breaking the individual systems into subsystems. They calculated the expected current versus measured, allowing them to clear shorts that had previously gone unnoticed because readings were within compliance values. After clearing these shorts the rectifiers were reset at a lower setting. In the future, all systems will be broken down for analysis into subsystems. Regulator Stations Initially a project was started to make sure that all stations had a standardized station sign. A list generated from the mainframe maintenance database was used to determine which stations needed signs as well as which name should appear on the sign. This list was compared to the stations that had been converted in GIS, revealing a high degree of mismatch between the lists. Entire stations were missing from one database or the other, and many stations had their names changed in one database but not the other. The complexity of such a seemingly simple task was a surprise to the team, especially that what should have taken days stretched into weeks and eventually months. The more research that was completed the more problems were found. After going in circles for three months, it was decided to step back and examine the entire regulator station maintenance process to understand how things had become so confused. Over the years anumber of secondary databases had been developed and populated in each of the divisions, and each division apparently had a slightly different way of doing exactly the same thing. The biggest problem was a lack of procedure for changes to be perpetuated throughout all the databases. The engineering department decided to take the lead and develop a new process that would standardize the procedures and centralize the data. All the different databases were collected and a new database design was developed. This new database was much more complex than the old one, and required significant changes to the field processes currently being performed. The primary task was to ensure that for every regulator station on the system the following information was known:
The number of revisions that came back was somewhat surprising. Some stations had been changed so much that they did not resemble the drawing sent to the field. Others required the majority of their data fields updated. In some ways this process resembled an internal re-conversion of all station information. Prior to this effort the consensus was that the stations were in pretty good shape. It was now clear to everyone just how much work was involved in getting them up-to-date. Three major benefits have been realized so far:
Emergency Shutdown Emergency shutdown was one of the first field office applications developed by GIS. After looking at a number of off the shelf solutions it was decided to take a shot at developing something in-house. The application had to work within the current GIS environment and be easy to use in stressful situations. In less than three weeks an application was up and running within the framework of our existing viewing and query application. Using the existing view/query system was beneficial because many people had already been trained in using the viewing tool in all four of our division offices. Thus, the application was so simple to use that it did not require a separate training class. All users were trained over the phone. The application allows one to identify a gas leak in any pipe or fitting on the system. It then identifies the fewest number of valves required to isolate the leak and highlights the entire area effected by the shutdown. Then the user has the option to print the list of valves and their locations or display them on screen. This tool has been used throughout the service area to handle the common 3rd party damage leaks as well as gas emergencies created by natural forces such as hurricanes. After completing the on-the-fly tool it was necessary to examine how the Gas side of the company was currently meeting DOT requirements for emergency planning. Once again an entire division was selected for a pilot. All of their existing shutdown maps were used to create an application to test and validate their plans. The first step was identifying all valves required to isolate each individual zone and build an emergency shutdown database. After the zone files were created, each zone was tested to see if gas could get in or out of the zone. Surprisingly, on the first pass only 20 percent of the zones passed without modification. In retrospect it might have been easier to start with a small town for the pilot but instead the largest and most complicated division was used. The logic of that decision dictated that whatever would work in the most complex system would work everywhere else, and for the most part this belief held true. For two weeks the Gas GIS team worked with the local technicians to solve the problems with their existing zones. In some cases it was as simple as adding a valve or splitting one large zone into smaller more manageable zones; in other cases areas that could not be isolated without cutting in new valves were identified. Once the pilot was finished, the process to test and fix the zones for the rest of the divisions began. This procedure was extremely valuable and time-saving, and also ensured that in the event of a major problem all solutions had been tested prior to implementation. Thus, the need for an annual process that consumed resources in every one of our offices was eliminated. Now a centrally maintained system that leverages existing investments in technology has replaced a cumbersome, inefficient, and inconsistent process. The final products consisted of the following:
Summary The success of these four applications would not have been possible without the cooperation between the field personnel and the GIS team. The many problems that were encountered only served to strengthen the relationship between the users and the programmers. The field personnel now feel as if these applications are truly theirs because they have had a hand in shaping their development. It takes more than re-engineering to make a process better. It takes an understanding of how work is a currently performed versus how the technicians would like to perform it. Sometimes the good part of the old system is thrown out with the bad, causing the new system to be viewed with skepticism. Another important thing to note is that each of these four applications was built with "yesterday's technology". Instead of spending time rewriting existing applications in the latest language or version of software, resources were focused on building new applications that would work with software that already existed at SCE&G. One of the most difficult decisions a manager has to make is when to upgrade to new technology. Often, it is too easy to run aground while migrating to a different version or software vendor. The flip side of this argument is that now SCE&G has more applications to migrate when the time is right. If hard dollars were the only factor used to make the decision it may have been less expensive to migrate before these for applications were written. The deciding factor that led to the direction outlined in this presentation was the customer in the field. They are not interested in what programming versions or software vendors; they are interested in timely delivery and a stable environment. In some instances they may not get all of the functionality that the newer versions promise, but in all cases the product is better than what was available to them previously. In the end it wasn't the software or the people that were the most trouble-- it was the data. If the process had been delayed for the newer software to be perfected, the data themselves would have never have been perfected. What can be learned from this presentation? GIS does not have to be painful. Finding out how people in the field would like to do their job and match it with what existing software can already perform is the key to successful implementation. Most people would love to drive the best car or have the biggest house, but are more than happy just to have transportation or a roof over their heads. GIS users aren't much different: something today is much better than nothing. | ||
| © GISdevelopment.net. All rights reserved. |