What's in the Field: PC or Appliance?

Paul M. Wilson
MapFrame Corporation 100 N. Central Expressway, Suite 1008 Dallas, TX 75201

Abstract
Current platforms for field computing are based largely on the existing model for desktop computing: field applications run in a multi-purpose environment along with an office suite, a browser, and various other packages. This paper suggests that, in the future, field computing will come in a variety of forms but, increasingly, it will diverge from this “PC on a stick” model. Instead, many mobile solutions will take the form of highly specific information appliances that are cheaper, simpler, and more relevant to the task at hand. This paper examines the conceptual differences and looks at examples of utilities already utilizing appliances in the field.

While field computing follows the general trends of the computer industry -- with hardware getting smaller and closer to the place of work -- it also suggests a paradigm that at first glance appears to be new. This is the emergence of the PC versus Appliance option open to those who are developing and implementing field applications. This option extends to applications of even the most advanced type involving large databases and graphics.

First, what is meant by appliance? This is a term that has evolved in the past few years to describe a highly specific information-based platform, usually something that can be carried with a user and accessed on an “as needed” basis regardless of the setting. For most people, there tends to be an assumption that an appliance is small, limited, and cheap: cell phones, pagers, PDAs. Most appliances do fall into this category, but it is worth noting that the term “limited” may be the most important defining characteristic of an appliance, at times overshadowing both size and cost considerations.

In the utility industry, specialized computing appliances have a long history. Small devices for meter readers or pole inspectors, for example, have been used for years. Although these devices have fallen under the strict technical definition of computers, they were limited to one specific task.

By comparison, a PC is not limited, at least in a relative sense. For those of us who are involved in the development and use of field applications involving GIS data, the PC model is the one we have favored for obvious reasons. We have not been able to provide effective applications in the constrained environment of a handheld computer (e.g., Palm Pilot) with its limited storage, and small screen size. Even where the use of a field computer is constrained to a narrow application, the response has been automatic. Need maps? Get a PC.

In fact, high-end mobile computer vendors have gone to great pains to distinguish themselves from appliance manufacturers, insisting that “you can do almost everything on a mobile computer that you can do on your desktop.” The desktop paradigm has embodied mobility and morphed into the “PC on a stick” model. Even high performance pen computers designed specifically for the field run in a multi-purpose environment today along with an office suite, a browser, and various other packages. Attach a keyboard, vendors assure us, and you have a PC.

So what’s wrong with that? Maddeningly, the answer is both nothing, and a lot. Like most things in life, there are trade-offs and ambiguities inherent in the PC v Appliance debate. What we all want, of course, is the ultimate: a smallish, lightweight computer with virtually unlimited battery life, a great outdoor screen, a screen large enough to view maps, plus we want a lot of storage. And we definitely want cheap.

Obviously, we’re not there yet. But we are getting closer. Windows CE is an attempt to join a PC operating environment and an appliance form factor. The Palm OS supports several handheld computers that – in addition to serving as organizers – are being used with spatial data. We’re beginning to see dramatic improvements in the appliance technology and we’re also beginning to see “early adapters” moving map-based applications onto CE and Palm platforms.

There will certainly continue to be compromise for some time to come in the computer as appliance market (both in terms of the developer and the user), but there is no doubt we are headed toward the manufacture of a more fully developed appliance. This is true if for no other reason than cost. Large deployment of field computers requires hardware costs to come down.

So what do we do in the meantime? Let’s consider the earlier point about defining an appliance. The term “limited” may be a more useful way to think about an appliance – at least for now – than even size and cost. In other words, there are reasons to use an appliance besides cost. And, conversely, you can have an appliance that isn’t cheap.

For some developers, the key to thinking about “limited,” at least in terms of field computing, is a zen-like anomaly, i.e. limited may actually result in more rather than less. To buy into this theory, you must agree that “limited” can be viewed in both a negative and a positive sense. The negative aspect of the term limited is a discouraging “can’t do much” definition. Turn limited on its head, however, and you get the concept of specific. In many ways, specificity is the key to successful mobile computing, no matter what the platform. And that brings us to software.

A travel analogy may be the best way to think about specificity and mobile computing. When most people go on a business trip, they tend to pack lightly because they know instinctively that the more luggage they have, the more hassles they have. It’s the same with mobile computing. Mobile computers are designed for travel and they work best when excess baggage is eliminated.

In the case of software design, that means specificity. The more specific the application, the less likely it is to be overloaded with excess baggage. This, of course, flies in the face of the current software trend toward big and complicated. Big and complicated may be OK for the desktop (although this is arguable), but it shouldn’t be extended to a field environment. The “PC on a stick” model isn’t attuned to a limited environment. It is predicated on the “put your entire desktop on your computer” model.

So we’re back to the question, what’s wrong with a desktop model for a mobile computer?

Even with a laptop or a high-performance pen computer, there are still storage and memory limitations. So Rule Number One is take only what you need to the field. Get rid of extraneous functions. View the laptop or high-performance field computer as an appliance even if it is bigger and more expensive than what you normally think of as an appliance. Don’t take general purpose-software to the field; use the computer as a field tool with a specific application for pole inspection or distribution design or facilities repair. Eliminating extraneous functions will help you fit all the information you really need on a mobile computer, even parts of large databases and graphics.

Rule Number Two is the same as Rule Number One: take only what you need to the field. Be specific. Field personnel aren’t trained to use a complex, general-purpose GIS. Some of them have never used a computer. Understandably, they don’t want to learn a complex system that has little relevance to what they do every day. And the fact is that many people working outside the office do virtually the same type of thing every day. For them, specificity provides the optimal tool they need to do that job.

Those of us who believe that access to GIS data can greatly increase the effectiveness of field applications need to make it specific. We need to integrate specific mapping and spatial analysis tools into applications packages with language and standards reflecting the job. When you do that, you have an appliance which field personnel view as just another tool to help them get their work done. The “appliance mentality” makes for an application that is easy to learn and use and that also insures user acceptance.

Tradeoffs
How does one decide between PC and appliance? The categories themselves are fuzzy, but we can certainly generalize about some of the factors that characterize each category.

Typically, an appliance will be smaller than a PC. That translates, on the plus side, to less weight and longer battery life. It also means, in most cases, less power and less capacity. The net effect is a more constrained computing environment – but one that can be used more places and for longer periods of time.

Another aspect of the difference is in complexity. An appliance is often more robust – there is simply less to go wrong. Today's PC architecture, based on an astounding combination of hardware and software components that mean no two machines are ever exactly alike, exacts a high cost in maintenance and system-related downtime.

The other side of this "less complex" tradeoff is a lack of flexibility. The beauty of the PC is that, by loading new software, it can be made to perform virtually any task. This may not be true of the appliance, particularly if it runs a nonstandard operating system where the software choices are more limited.

Costs are a major factor in any choice. Here, the appliance platform has a big advantage over the PC – although, over time, the differential will probably decrease. It is important to keep in mind that the true cost of deploying a system includes far more than hardware, however. Lower training costs might come with an appliance. On the other hand, the availability of lower cost mass-market software for the PC platform might outweigh its other disadvantages – if the software does what is needed.

Examples
So how does this work in reality? Let’s take a look at some examples of utilities that have gone the appliance route using a PC form factor.

Dominion Resources (Virginia Power & CNG) has just implemented a new service order management system that incorporates the use of maps on about 850 mobile computers. The system automatically assigns work orders to line crews and service technicians. Each service truck is equipped with a high-performance pen computer. Work orders can be downloaded at the start of the day or sent to field crews via wireless communications.

A map viewer is embedded in the system so field personnel can view facilities, maps, and attribute data for areas tied to the work order. The application functions as an appliance in several ways. First, it is set up so users never see the Windows desktop. Literally, this is a tool designed with specificity and ease of use in mind. The system automatically loads when the computer is turned on. So, even though this is a full scale Windows application on a full scale PC, users can’t access other functionality. The computer is being used as a dedicated appliance.

Another appliance-like feature of this application is the way the map viewer is linked to the field service order system. From an architectural standpoint, there are two applications running, but this is not apparent to the user nor does it require any action on the part of the user. Users tap a MAP button on the computer screen and a map showing the service order area then displays. A general-purpose map viewing capability exists within the framework of the application, but users can’t access this broader capability. All they can do is view map data within the context of a highly specific set of tasks, i.e. responding to work orders and repairing the electric network.

This example is one that requires some "PC" elements (a fairly large amount of storage, large screen, etc.) in its hardware platform. The architecture of the application, itself, however, is very directed toward the idea of a computing appliance.

Another example of the Appliance approach is a pole attachment application at Pennsylvania Power & Light (PPL). Like all utilities, PPL collects fees for allowing other organizations (cable, telephone, fiber, etc.) to use their poles for various attachments. But keeping track of “who” is using “what” pole is a difficult and time-consuming process, especially when using paper.

To solve this problem, PPL decided to go mobile. They replaced the old system with a highly specific mobile application. While visiting each pole, a PPL employee inspects it visually for attachments. If an attachment is evident, the user then checks the pole database on the mobile computer to see if the company has a record of the attachment.

If the attachment is in violation, the user adds the information to the system by selecting from a list of attaching companies and then adding attributes like number and size. The information is saved and uploaded to the corporate GIS and also to a customer billing system.

All of this activity takes place within the context of a map, but it is significant that the map data displayed is limited to objects important to the survey process. Conductor, transformers, and other devices are not displayed since they play no role in the business process. The application is limited in the sense that it is specific.

Conclusions
Increasingly, the computing appliance is a feasible alternative to do field work without giving up the power of spatial data. In many cases, the answer is a combination of hardware that acts like a PC and software that keeps it from acting like a PC – in short, a machine that may be a computer but is not perceived as one.

Ultimately, the choice between PC and appliance depends on the nature of the work being done. An individual who performs only one function (e.g., meter reading) is a good candidate for the appliance option.

At the other end of the spectrum, some utilities are moving towards multipurpose crews, where the job description may include design, construction, maintenance, and customer service. In some cases, it may include dealing with both electric and gas systems. With a broad set of application needs, these users are likely to need the flexibility of the PC approach because a typical workday requires access to a number of different applications. It's almost like serial use of appliances, but on a single machine.

No choice is right for every situation. The hardware and software selected for a given job has to match the requirements of that job. The good news for those deploying field automation today is that there is a range of choices that work well, matching power with mobility and fitting into the budget constraints of most organizations.