FAME Goes Mobile with Colorado Field Inventory

Mary Ann Stewart, P.E.
AM/FM Conversion Manager
UtiliCorp United
20 W. 9 th Street
Kansas City, MO 64105
Telephone: (816) 467-3289
Fax: (816) 467-9289
E-mail : mstewart@utilicorp.com

”When the bird and the book disagree, always believe the bird.” -- James Audubon

Prelude on Mobility and Field Inventories
Technical advances have made mobility a popular topic in our industry in recent years. The problem is, when we’re all taking about a large topic, we may be addressing very different sectors of the subject. The mobility issues to be discussed here involve taking data from an central office-based AM/FM system to the field in disconnected mode and returning data collected in the field back to the office system.

UtiliCorp desired mobility for its AM/FM systems for two main applications: mobile mapbooks and field data collection. We began with a field data collection pilot in anticipation of a pending merger with a utility company that had no maps. The plan was to pilot field data collection in 2000 and employ the methodology developed for a large scale field survey to begin sometime in 2001. We hoped that this pilot could assist the mobile mapbook effort by pushing desktop maps out to the field data collection system.

I began this odyssey believing that taking the book to the bird would improve the description of the bird. The field office participating in this pilot project set a simpler target--develop field data collection methodology that was an improvement over scribbling on the back on an envelope.

If you’ve never been on a similar voyage, our goals will appear absurdly small (we do have larger more sophisticated sounding goals, which can be created by any short brainstorming session). Unfortunately, the rocks of technological complexity surround this very attractive mobile touring spot. It is my intent to point out some of the more treacherous rocks and provide some clear navigation points to aid in reaching the goal.

The Odyssey Begins
Our odyssey in search of a perfect field inventory began early in the year 2000. Staff for UtiliCorp’s AM/FM system, FAME, were receiving a flurry of phone calls from field staff in Canon City, Colorado. The Canon City staff had been capturing latitude and longitude points using consumer grade GPS units. They wanted help getting these points correctly into FAME because the points were landing on the wrong side of the street as often as not.

Those with experience in enterprise-wide GIS solutions are now wisely shaking your heads and inwardly screaming “Nooooo.” To expect your corporate AM/FM system to accommodate the desires of a small field office while allowing self-trained non-IT staff to collect vital data would surely be the kiss of death. Any manager who has endured the wars of diverse internal agendas would be strongly inclined to run for the hills.

But wait. UtiliCorp’s goal for its high dollar, multi-year reengineered AM/FM system was to decentralize map maintenance, putting tools in the hands of the local design and field staff and making them responsible for their facilities information. During the growth of our project, many corporate and district level needs for this mapped data had been discovered. Many stakeholders now expected our system to provide timely and accurate information about facilities. Canon City was saying that in order to provide this information they needed to be able to take measurements in the field, bring them into FAME, and have it all make sense.

The Odyssey Unfolds
We set forth to help Canon City with their data collection problem, hoping to extend the solution throughout the corporation. We soon realized that we did not fully understand their problem or goals and began to more pointedly question the staff requests.

Navigation Point: Don’t assume you understand a mobility problem based only on how end users or managers explain it to you. Especially don’t assume you understand the ultimate goal upon first hearing it.

Why did they need to get latitude/longitude points into our system? Canon City field staff were required as a result of our reengineering project to enter new facilities designs into the system. Typically these designs were for line extensions. Often the lines to be extended were not in the system. GPS measurements were being taken to provide a correct starting point for the designs. Most locations were in rugged terrain, with 40 acre lots, few roads and even fewer mapped landmarks.

What would a collected point location mean in the AM/FM system? A point could be a pole, a modeled object in our system. However, a point location could also be used to locate transformers or other devices which might hang on a pole. Two points could define a span of conductor. Further, points could define the location of components and spans in an underground system. Ultimately points could be used to describe many more parts of the electrical system, ranging from transmission lines to individual meter locations. Thus we reached the first major issue in our data collection plan. What objects would be appropriate for Canon City staff to collect? When do individual data collection efforts begin to fall outside the centrally planned scope of the AM/FM system?

Navigation Point: Providing field data collection capabilities raises the issue of local responsibility for data maintenance and scope. Be prepared to wade in.

How many points did they need to collect? Once we heard that lines were not in the system, we became curious as to the extent of this problem. It often turns out to be difficult to estimate the quantity of something left undone. We worked with the Canon City managers to estimate that half of the district was unmapped. They generally knew the location and extent of unmapped areas and could provide some data concerning number of transformers.

Why were the collected points wrong or unsuitable? This was the question that kicked off our pilot. Trying to answer the question became confusing. We looked at all issues associated with importing latitude/longitude into our system. We looked at the theoretical accuracy of consumer grade GPS systems before and after selective availability was turned off. We watched the staff collect data. We theorized that some degree of finer resolution in data collection was needed. All we really knew was that some points created from GPS measurements fell on the wrong side of the street in our AM/FM system.

The Odyssey Gets a Project Plan—And Funding
Asking all those pesky questions gave us issues we could summarize for UtiliCorp energy delivery management. The primary problem was not that Canon City staff needed methodology and tools to collect field data, but that they needed to do a lot of field data collection because half the district was unmapped. Given that the press of rapid growth in the area had caused the problem, it was probably unrealistic to expect the existing staff to work even harder to learn a new set of skills for data collection while muddling along with inadequate maps. Energy delivery management tasked the AM/FM team with outsourcing the field survey and developing an efficient methodology for getting the collected data into the system.

At the point of planning a field data collection procurement, we worked with energy delivery management to resolve organizational issues. We discovered that the Canon City staff desired to collect substantially more data than was deemed in scope by energy delivery management. The equation “points equals poles” became a problem. Scope of the AM/FM project had never allowed for collection or maintenance of data on individual poles. Canon City staff strongly preferred to collect and maintain individual pole locations and data. The compromise reached was that poles with transformers or other devices hanging on them would be collected, transformer station numbers attached to poles would be collected, poles indicating significant changes in direction would be collected.

Once it was determined which objects were to be collected, we begin to work on the data structure of the collection software. We wanted to create an efficient way to load field data into our Smallworld AM/FM system. Many of our electrical objects had complex parent-child relationships. Our first idea was to duplicate these relationships in the field data collection software, in order to produce output identical to our data structure. However, configuration of vendor-supplied software to duplicate our structure proved to be time consuming and difficult. UtiliCorp had a desire for a data loader product that would be flexible and easily used for all our electrical objects. We ended up working with yet another vendor to configure a data loader which would take ascii files exported from the data collection software and load them correctly into FAME.

By the time everyone’s piece of the effort was completed, summer was almost over. Our initial data collection efforts were to take place in the southern Colorado Rockies at 8000 feet. We had authorized 28 days of field data collection. We pressed hard to begin the data collection efforts. We attempted to run sample data through the field collection software and into the loader, but the field vendor had difficulty producing sample data. We went ahead to the field anyway.

Navigation Point: Always allow time to test the collection and load process before going to the field, no matter how much snow is predicted. There will be problems with the data structure, you will not be able to see all of the problems without running a bunch of data through your processes, and you must attempt to solve all the problems before collecting mountains of real data.

The Odyssey Hits Turbulence
We began the 28 days of data collection in early August. The vendor’s data collection person was experienced in electrical network data collection but knew nothing about our project. The Canon City UtiliCorp facilities designer was experienced with the network but knew nothing about the vendor-supplied software. The plan was for them to operate as a team and for their knowledge to ultimately become interchangeable. UtiliCorp field staff wanted to retain the data collection hardware and software after the core 28 days in order to use it in the field for design of new facilities. Unfortunately, the lead UtiliCorp designer would only be available half of the 28 days. Many different staff members would assume the role of driver, network tracer, data collector. This increased the participation level of the field office, but also increased the confusion level.

During the first week of data collection the vendor data collector valiantly tried to understand what was important to the UtiliCorp field and corporate office staff. By working with him in the field, we began to see real problems in the design of the data collection process. The field model was too complicated. In one case, data entry required opening 34 separate screens on the laptop.

The data collection software appeared to have evolved from a simple GPS point capture process. Although it was all too easy to provide multiple screens for data capture of individual electrical objects at a point, describing the connectivity of our network was cumbersome. Connectivity was captured through the process of incrementally numbering electrical objects as a circuit was traced out from a substation. Any edits to the incremental numbering system could involve tedious manual renumbering of the objects. The software could only describe objects as points and was thus incapable of any graphical description of electrical conductors. With only points and landbase backdrop loaded in the field software, there was no graphic display of the network that was being captured. Intuitive field-based QA/QC was impossible. The data collection person could not completely see what he was doing for the critical part of the network trace.

We had cleverly designed a day’s end data load process in which the field collection person would perform post-processing, email the data to the UtiliCorp corporate office for immediate loading, and thus allow the field crew to view the previous day’s work in the morning before setting out to collect more. This is a great technical approach. However, we were never able at any time in the 28 days to collect clean enough data for immediate loads. Data was cleaned extensively at the field data collection vendor’s office, at the data loader vendor’s office and at the UtiliCorp corporate office.

Navigation Point: The difficulties with data loading show that our field data collection structure was too complex and that the software was not performing well for the task at hand. This emphasizes the point that you must run lots of sample data through your processes before going to the field. It is very difficult to postpone a voyage when winter is bearing down on the site and managers are demanding data now. However, you must find a way to bench test the system and fix problems. The fixes may not be all that quick or easy. There is no acceptable way to fly by the seat of your pants if your electrical (or gas or telecommunications or water) model is at all complex.

The Odyssey Rescues Itself and Sets Course for Home
We were fortunate in having planned a short 28 day project. Although spread out over large tracts of land in two counties, the entire project described only five electrical circuits. With this small amount of data, it was possible to postprocess the field data using a mix of programmic and manual edits. Manual intervention further revealed errors in the GPS collection process due to a firmware error. We began to wonder if our data would ever be usable.

As postprocessed data was loaded into our system, the field staff was finally able to review the data they had collected. We expected all sorts of electrical network issues to rise at this stage of review, but were surprised by the single biggest criticism of the field inventory from Canon City staff. The GPS points were still not falling on the right side of the street. Our attempts to solve this problem had created the entire field inventory project, but we still hadn’t solved the problem. The vendor assured us that the GPS measurements were correct after fixing the firmware error. What was the problem?

Close examination of our landbase revealed a variety of issues. The original landbase source was probably county data, but dates and processes had been lost in the mists of time. Incremental addition of subdivisions by UtiliCorp drafting staff had further altered the landbase. We could not ever expect a relatively inaccurate landbase to fit our GPS measurements.

We canvassed the local agencies for more accurate landbase. Responses were not encouraging. Canon City staff were stuck in the middle of technology change. They couldn’t go forward with GPS technology without good landbase to support it. They didn’t want to go back to the old methods of guessing where things were when good measurement technology was available. Our current solution to the landbase problem is to work with a Colorado GPS/GIS/surveying firm to reproject the landbase for the field inventory area. The lot lines, street centerlines, right of way lines, and waterways will be fit to the GPS centerline data collected during the field survey. Watch for updates on this very promising approach.

Navigation Point: While engaged in a complex field data collection project, steer a true course based on the original goals of the project. Strive to accomplish these goals (points on the right side of the street) even when it does not appear possible. If you worked to understand the true goals at the outset of your project, you know for sure where you’re going and will find a way to get there.

Lessons Learned
The biggest lesson we learned from our voyage was to take small trips before large ones. Blunders along the way did not turn into tragedies due to the small scale of this project. Mobility and field data collection projects raise complex technical issues concerned with emerging technology. We (and now three vendors) were compelled to deal with our full electrical data model in order to correctly describe the distribution system of a small part of our Colorado service territory. This is too much effort for a small project, unless it is phased as part of a greater long-term goal.

Reducing complex data models for use in the field can be a big issue. GPS data logger software has grown out of the simple concept of collecting attributes describing a point location. This simple structure can be great for ease of data collection but will offer challenges in trying to describe something as complex as an electric distribution network.

Navigation Point: Give data structure a lot of thought. Listen to what others are doing and think about how their solutions may relate to your data structure and field collection plans. A good solution should not require data entry on 34 separate screens while in the field.

We learned important lessons about ownership of data from this project. It’s important to have the local staff involved with a field data collection project, even if it’s necessary to outsource the data collection. Working with the Canon City staff to determine what is acceptable data has been critical to the success of this project.

Landbase errors continue to be a potential deal killer for our GPS inventory process. Introducing highly accurate point measurements of facility locations demands a comparably accurate landbase. Our end users are usually not familiar with the technical and cost impediments to providing highly accurate and current landbase for their area. However, a number of them now would like to locate individual customers in their correct lot, preferably with a point centered in that lot. To date, landbase improvements have been made on a case by case basis in areas where there were specific problems or where unusually good landbase became available. It has been difficult to develop a comprehensive landbase improvement plan due to the high cost of such an effort for our primarily rural, multistate service territory. We know it will be impossible to move forward with the dream of GPS located facilities without significant improvements in landbase.

Planning the Next Voyage
Our scheduled voyage, a large field inventory for the company with no maps, was cancelled at the beginning of 2001 with the announcement of the termination of a proposed merger. This was of course very disappointing for the overall field inventory effort, but has given us time to think about the next project, whatever it may be.

My dream for the next voyage would be to have a software tool that would integrate map book and field data collection functionality (it would be nice if it could run our design application as well). It would easily load our existing AM/FM data, run well in a detached mode, be easily customized for a specific field inventory task, and permit easy loading back into our system. Currently, there does not appear to be a single software product that will do all of the above with our Smallworld system. If we must invest time and dollars to create such a tool, we would do well to make it as extendable as possible while providing the desired functionality. We don’t want to build a tool that is too small for our growing needs. Although we are able to create detailed specifications according to our current needs, we find that business changes are coming rapidly. Already we are considering the addition of telecommunication networks to our AM/FM system and to the field inventory process.

My other dream would be to have greatly improved navigational charts for the voyage. Improving landbase will become more of an issue as we have more users for our AM/FM system and more applications, such as business geographics, available to them. Landbase errors will glare more sharply as GPS technology, satellite imagery, wireless technology come into common use.

The interesting challenge of mobility for AM/FM systems is charting the best possible course to a destination that changes with the business climate, using imperfect data that is being altered as you move, while integrating rapidly emerging hardware and software technology. Good luck and watch out for the rocks!