Stephanie Guerlain, Jim Lee, Troy Kopischke, Tom Romanko, Peter Reutiman and Scott Nelson. Honeywell Technology Center, Minneapolis, MN, USA.
Mobile Networks and Applications 4 (1999) 37–48
37
Supporting collaborative field operations with personal information processing systems Stephanie Guerlain, Jim Lee, Troy Kopischke, Tom Romanko, Peter Reutiman and Scott Nelson Honeywell Technology Center, Minneapolis, MN, USA
This paper describes a two-year research project to develop a personal information processing system (PIPS) solution for the roving industrial field operator. Our PIPS system comprises (1) an RF network to deliver wireless digital information, (2) a wearable computer for delivering web-based information (the hardware is a two-piece system composed of a belt-worn NetPC attached via a curly cable to a handheld unit with a mouse/display device combination), and (3) software applications that provide added value in the field. Unique challenges in designing such a system for this environment include providing: (1) good RF coverage in an environment with many metal structures; (2) an intrinsically safe, lightweight, low-cost hardware system; and (3) software that is compatible with the wearable system and supports collaboration in the field.
1. Introduction
2. Year 1: A proof-of-concept first-generation system
Honeywell has a long history in developing miniaturized displays, custom microelectronic hardware, and wearable, portable devices, primarily for military applications. More recently, Honeywell researchers have been trying to apply these technologies to the specialized commercial market of supporting the roving refinery operator in the petrochemical and oil and gas industries. Many of the needs in this market are similar to military requirements; namely, the systems must be ruggedized and able to handle harsh environmental conditions. Less similar are the social implications of introducing such innovative technological solutions into an environment where the work force is primarily union-based and personal routines vary widely. In this environment, current communication is primarily face to face or via twoway radios and information tracking is scattered and largely paper based. Our goal in trying to adapt personal information processing systems (PIPS) to the refinery field operator environment is to produce a system that fits the needs of the environment and the individual workers, and adds value by providing an infrastructure that supports collaborative field operations. Our systems-based approach to this solution can be broken down into three related parts: (1) develop an RF network infrastructure to support wireless, digital communications; (2) design a wearable hardware system customized to the refinery operator’s needs; and (3) develop software tools and applications that are personalized, intuitive, customizable, and support collaboration in the field. The project proceeded in two stages. In year 1, we developed a proof-of-concept first-generation system. In year 2, we developed a more complete package worthy of field testing in a refinery environment. This paper describes the design goals, actual designs, and preliminary evaluation results from an internal as well as a field evaluation of PIPS.
Our first-generation PIPS system was designed as a proof-of-concept system that we could show to potential customers. Early prototypes of the wearable hardware consisted of a commercial-off-the-shelf (COTS) belt-worn Windows 95 computer combined with either a hard-hatmounted monocle display device (see figure 1) or a handheld unit (called the Eyewand) that combines a miniaturized projection display and a three-button user input device (see figure 2). In focus groups with field operators, we found they were reluctant to have a head-mounted system that could obstruct their vision (even though we had designed a flip-up mounting), added weight to their head, and was likely to get bumped endlessly by obstructions typical of the refinery environment. Thus, we concentrated on the handheld unit. Wearable and tablet computers are typically plagued by screen size limitations and/or user input challenges [3]. A miniature projection display design offers the advantage of a high-resolution display in a very small package. Our first-
Baltzer Science Publishers BV
Figure 1. Integrated hard-hat/display device.
38
S. Guerlain et al. / Personal information processing systems
Figure 2. The three-button Eyewand.
generation Eyewand had 640 × 480 (VGA) resolution, and our latest models have 800 × 600 (SVGA) resolution. This type of resolution allows us to design fairly typical desktopsize user interfaces, important in a refinery environment for being able to display sufficient information (diagrams, schematics, and procedures). However, how to navigate through the software and perform data entry tasks is another question. (The software team did consider speech recognition as a supplemental input device to the system, but in the high-noise environment of a refinery, we determined this would not be a viable option.) By opting for the handheld Eyewand approach rather than the helmet-mounted monocular design, we were able to incorporate a user input device into the same hardware as the display device. We wanted the input device and software navigation scheme to be simpler and easier than a windowing, desktoptype environment. Since a mouse potentially provides a handheld unit with unnecessary functionality at the expense of ease of use, our initial Eyewand design had three buttons. However, we eventually abandoned this approach in favor of a direct-manipulation pointing device (a force-joystick “eraser head” mouse) because the need to format data into the structure required by this navigation scheme (and the need for development tools to do so) made the system too customized and proprietary for the customer base to want to adopt it. Thus, the tradeoff between (1) having an extremely easy to use user input device/software navigation for the field operator and (2) ensuring flexibility and customization opportunities by the customer site fell on the latter side and led us to abandon this hardware/software combination and go to a more traditional point-and-click (direct-manipulation) user interface scheme for our secondgeneration system. Although we eventually abandoned the three-button approach, we describe below the software navigation scheme we developed as it may be of interest to others who plan to use a three-button user input device. 2.1. Software navigation with three buttons We mapped the three buttons on the Eyewand to Up Down, and a multifunction Enter button. Users navigate
between displays via a pop-up menu, and navigate within a screen by following a tree navigation scheme or a circular navigation scheme (explained below). Pressing and holding the multifunction Enter button calls up the pop-up menu (see figure 3). Once displayed, the user navigates the menu by using the Up and Down buttons on the Eyewand and selects an option by pressing and releasing (clicking) the Enter button. The pop-up menu is divided into three parts. The center of the menu shows Cancel, which is the default option when the menu is displayed. Selecting this option cancels the menu display in case the user called it up by accident or wishes to go back to the screen they were working on. The top part of the menu shows the major applications available. For example, in our prototype, the user can navigate to Personnel, Maintenance, Process Data, and Email. The bottom part of the menu shows context-sensitive menu items: the options are relevant to the task the person is working on when calling up the menu. For example, when looking at a process control screen, the pop-up menu includes options for viewing schematics and data trends. If no context-sensitive options are available when the user calls up the menu, no options are displayed in the bottom part of the pop-up menu. Navigating around a display with only the Up, Down, and Enter keys is achieved primarily using a tree-based user interface control. For example, in the Process Data application, the main screen uses a tree structure as a means of navigating to groups of data that are related to pieces of equipment (e.g., Compressors, Towers, Furnaces). The user can navigate the tree by using the Up and Down buttons on the Eyewand and can collapse and expand the tree by clicking the Enter button. If at an end node, clicking the Enter button performs the default option for that item. For example, when viewing a procedure step as an end node in the Procedures screen, clicking the Enter button serves to check off that step. We also incorporated an alternative type of navigation within an application window that we call “circular navigation.” For example, using the context-sensitive menu options available when viewing process data, one can navigate to trends of the data and schematics that show the data in a process flow diagram format. These screen types do not display a tree structure. Rather, they are specific to the process data being displayed on the main screen when the menu option was called up. For example, if one selects “View Schematic” when looking at the C-3 tower process data, the schematic displayed is relevant to the C-3 tower. Once viewing the schematic, the user can “circle around” the display in one direction by continuously clicking the Up button and “circle around” the display in the other direction by continuously clicking the Down button. When viewing trends of the data, the trend related to one point fills an entire screen, so pressing the Up or Down buttons cycles the user through a set of trends related to the group of points in question (in this case, the six points related to the C-3 tower). Navigating back to previous screens is done us-
S. Guerlain et al. / Personal information processing systems
39
Figure 3. The tree structure and pop-up menu design to support navigation with a three-button user input device.
ing the context-sensitive menu, which now has options for closing the currently viewed screen. This prototype system was evaluated by refinery operators and engineers from several national petrochemical companies. Results of the study showed that the navigation scheme was remarkably easy to learn and use [2]. Novice computer operators unfamiliar with the Eyewand could learn to use the system very quickly and had no problems manipulating the input device or navigating through the system. Furthermore, quite a variety of information could be logically organized into screens and easily found by the user. Although it was originally a challenge to design a navigation scheme with only three buttons, we were surprised at the amount of functionality and flexibility this scheme afforded. We were also pleased to realize our original design goal of having an extremely easy-to-use, simple operating system. 3. Year 2: A second-generation, field-testable system Our first-year efforts were successful enough to warrant a second-generation design activity, with the goal of developing a system capable of field testing in a refinery environment. The field test system required us to develop and install an RF network, develop a hardware platform that passed intrinsic safety requirements of the refinery industry, and develop actual software applications that were linked to live process data, delivered real procedures, and
could be configured by the customer site and customized by the end users. We made an early decision to make our secondgeneration system web-based. We did so for several reasons, primarily to have a “thin client” NetPC as our wearable computer rather than a full-up Pentium-based computer. This would enable us to design a smaller, lighter weight, lower cost system with better power management and a longer battery life. A second advantage of using a web-based system is that it provides an existing infrastructure for collaborative operations. By linking our system into the corporate intranet, personnel can log on to the field operator’s web site throughout the refinery to see the current status of activities and can interact with personnel through the web site, if necessary (such as by scheduling tasks). Finally, designing for the web is becoming commonplace and thus provided us with a more open development platform, which was requested by the customers at the end of our first year’s effort. Our test site consisted of four functionally related “units” at a petrochemical refinery. (A unit is a logical subsystem in a refinery.) The units are run by a shift team (there are three shifts per day) consisting of 11 people: a shift supervisor, two central control room operators, two outside chief operators, and six field operators. Routine field operator tasks include conducting rounds, inspecting equipment, gathering routine maintenance data, taking samples, and preparing equipment for maintenance. Nonroutine tasks can include
40
S. Guerlain et al. / Personal information processing systems
activities as extreme as firefighting. Operators often have to climb ladders and routinely carry a flashlight, two-way radio, and hand tools. They wear fire-retardant protective coveralls, hard hats, earplugs, safety goggles, and steel-toed boots. We intended to support primarily the six field operators in this field test, providing them with wearable hardware and access to procedures and process data, although the chief operators and central control room operators (as well as others in the refinery, such as maintenance personnel and engineering) would also benefit from having access to the web site from anywhere in the refinery to get an overview of the field operations, as well as from having on-line data logging and a centralized, on-line repository for procedures. The following sections discuss the implemented designs further.
4. The PIPS RF network for industrial applications Oil refineries present a difficult communication environment due to the large quantity of pipes, metallic structures, and reinforced buildings. The RF communication coverage not only had to support activities of up to 10 operators in a 1000- by 1000-ft area but also on the top levels of 13-story structures. We wanted to maximize the transmitted data rate with the constraint of maintaining seamless connectivity in the harsh RF environment presented by the obstructions of the oil refinery. Workers can be located in very shielded areas such as metallic elevators, metal sheds that protect pumps, generators, and so on, and dense populations of pipes. Implementation of the wireless Local Area Network (LAN) focused mainly on the 2.4-GHz Industrial, Scientific, and Medical (ISM) frequency band because of the bandwidth for data transmission and a license-free operating frequency. A main access point was used as a wired link back to the main server. Additional repeaters were set up to ensure a link could be made between a mobile worker and the main access point from any location in the demonstration area. The wireless LAN hardware operates as a Direct Sequence Spread Spectrum (DSSS) at a data rate of 354 kbit/s. This is lower than a maximum of 2 Mbit/s to allow for greater range. Communication range is heavily influenced by the amount and type of obstruction between the antennas as well as the antenna gain. Maximum transmit power was 100 mW. This application required omnidirectional performance, so the antenna gain was less than 6 dB.
5. The wearable hardware In our current design, the wearable hardware is split into two modules: a separate processor/RF computer radio battery box attached via an umbilical cord to a handheld input/output display system (see figure 4). In our
Figure 4. The Eyewand attached to the NetPC. Table 1 Relay optics design specifications. Field of view
25 deg H × 20 deg V 30 deg diagonal
Resolution Nyquist acuity Minimum eye relief Diopter adjustment
800 × 600 24-µm pixels ∼20/37 for the AMLCD 32 mm None
view, until technology improvements in batteries and component/packaging miniaturization allow complete integration of all these modules in a sufficiently small, lightweight package, this split design offers the most wearability, convenience, and comfort for the typical industrial worker. 5.1. The eyewand input/output system The Eyewand design was finalized in year 2. It is a handheld, monocular, see-around display device with integrated mouse, using a commercial-off-the-shelf miniature 35 mm format active matrix liquid crystal display. The case shape was designed to be held while wearing cold-weather gloves, with a top-mounted, integrated single-button mouse (forefinger button/middle finger pointer actuation). A recessed thumb well includes a safety switch to prevent accidental mouse actuation during holstering (serving as part of the display’s power management system). The miniature flat panel display is a monochrome device with 800×600 pixels (SVGA), using a cold-cathode-type fluorescent backlight. With the proper polarizers and drive signal format (see table 1), this device is capable of 256 gray levels and 200 : 1 contrast ratio performance. With these optics and the backlight described above, the minimum luminance at the viewing eye is 50 ftL. A single eight-layer surface-mount board was designed to drive the
S. Guerlain et al. / Personal information processing systems
41
Table 2 Werable PC design specifications. Operating System–Hardware Support Java 1.1 web browser, 800 × 600 Architecture PEL resolution for FPD, mouse support Processing Performance Figure 5. Logical design of the NetPC and Eyewand.
display using the display chip set as well as incorporate a mouse pointing device. A single shielded 11-conductor curly cable with a standard 15-pin D PC display connector completes the Eyewand system. Total assembly weight with umbilical cord is 453 grams, or just under one pound. 5.2. The wearable computer To support the field test, we were not able to use an existing wearable computer, as none of the currently available systems meets the Class I Division II “intrinsic safety” requirements of the petrochemical industry. Further, the design team evaluated current wearable products on the market and concluded that they did not meet the design specifications because: (1) processor performance was excessive for the application, (2) hard disk storage was not necessary; the web pages could be cached in RAM, and no application storage is required on body, (3) the devices were large and cumbersome, (4) power requirements would not provide 8 hours of continuous use, and (5) none were UL1604 approved (Class I Division II, “Intrinsically Safe”). 5.3. Thin client approach With the presence of an RF LAN, a thin client processing approach using a COTS Personal Digital Assistant (PDA) processor becomes a viable alternative. The advantages of PDA processors are low power consumption and firmware operating system availability, eliminating hard disk storage. Further, they meet the size and weight requirements for the application. Figure 5 is a block diagram of the planned wearable processing system. The preliminary hardware specifications are listed in table 2. As it turns out, we have not yet fielded our PDA processing system due to lack of hardware availability and an operating system with a Java-compliant web browser. As an interim solution, we had to customize an existing commercial wearable computer system (the Rockwell “Trekker”) that, although chosen because it came closest to meeting the intrinsic safety requirements and could accommodate the type of RF LAN we installed, was much bigger and bulkier than we wanted and our customers are willing to use beyond the initial field test. The Trekkers were modified to include an RF modem and antenna, and connect to the Eyewand. They weigh close to 7 pounds, with a footprint of 1100 × 300 × 500 . Batteries last about 3 hours. They are too big to holster, and are thus best carried in backpacks.
Flash
RAM Peripheral
Display Drive Circuitry Weight Size Battery Life Operating Temperature Certifications
Operating System (OS) Java Virtual Machine (VM) Java-compliant web browser OS storage Java VM storage Java-compliant web browser storage 32 Mbyte RAM for web page storage Standard mouse RS-232 interface Serial, parallel, or PC card interface for RF LAN Monochrome 16 gray scale SVGA 800 × 600 resolution @ 60 frames/sec Same as radio, ∼1.5 lb Same as radio, ∼1.5 lb 8 h continuous use Rechargeable battery implementation −40 to +70 ◦ C Class 1, Div. 2 UL1604 for petrochemical environment
6. Application software Because our second-generation system has a directmanipulation input device, we were able to design a more traditional, mouse-based user interface in the second year. The application software was client–server to take advantage of the RF network, minimize power consumption requirements for the client, and support collaborative operations across users in the refinery. Our goals in designing the application software were twofold: (1) make the software personalized, customizable, and collaborative, and (2) develop core software functionality that demonstrates the utility of the PIPS system. After surveying the customer base [1], we prioritized a list of applications that we wanted to demonstrate: (1) routine duties, checklists, and other procedures; (2) data entry log sheets; (3) task schedules; and (4) access to process data. The client applications are written in Java to accommodate the need for “pushing” live data to the client. The PIPS server accesses near-real-time process data from the refinery’s history module (a system that captures process data to a database to historize it). The PIPS server also accesses a relational database that we designed to suit our needs, as much of the required information is currently paper based or scattered throughout various information systems in a refinery. The database is designed to store procedures, task schedules, and personnel information. It also stores sign-offs of procedures and data entry logs taken in the field, and provides a mapping between procedures and process data, so that live process data can be displayed in the middle of procedure steps when relevant. The database also stores an individual user’s “favorite” process points and groups of process points so that operators can personalize and customize the environment to suit their needs. This way, users can have some “ownership” of the system, since the hardware itself is shared by operators (the intent
42
S. Guerlain et al. / Personal information processing systems
Figure 6. Interactive, on-line procedures can be worked on simultaneously by different users. Sign-offs are updated in real time to support collaboration.
is to have enough devices to cover all the positions worked by a shift team, but as people change shifts, they would pass the device on to the next person). We also developed database maintenance and configuration tools to allow customers to customize the relational database to their site. We developed a tool for editing employee records, including a record of qualified job skills for each employee, so that employee skill levels can be matched to requirements of various procedures. We also developed a tool for entering procedures. Each procedure can have an associated set of steps, each of which is assigned to one or more job skills. One can also configure process data to be displayed as part of the step or link a data entry control (such as an on-screen keypad) for capturing an outside reading taken from the field. Finally, administrators of the system can schedule procedures to be done either once or periodically (every shift, daily, weekly, monthly, or annually), using either the database maintenance and configuration tools or the client web-based software. In our test system, we entered and scheduled all routine daily, weekly, monthly, and annual tasks for the test site (about 400 procedures in all).
The client software used by a field operator has an opening screen for logging on to the system. Employees at the refinery are grouped into four groups (A, B, C, or D), so users log on by selecting their group, name, and current job skill from a list of jobs they are qualified for (many operators are qualified for more than one job) and enter a numeric password via an on-screen keypad. (Since our hardware design has no keyboard, all data entry is currently done using on-screen controls.) Once logged on, users can navigate to various applications using the task bar located at the bottom of the screen. The “View Today’s Tasks” option (see figure 6) displays all scheduled tasks assigned to the employee’s logged-on position for the current shift. The user can select a task from the list of assigned tasks at the top of the screen, and the associated procedure is displayed at the bottom of the screen. Only those procedures that contain steps for the employee currently logged in are displayed by default. This limits the number of procedures displayed for any given person (although the employee can choose to show all tasks or those tasks assigned to another job skill, if desired). Some procedures require multiple people to perform them. Those
S. Guerlain et al. / Personal information processing systems
43
Figure 7. Example of a procedure that shows live process data to allow users to compare “inside” control room readings with “outside” manual readings, eliminating the need for radio contact with the control room operator for this type of information.
steps that are assigned to the operator currently logged in have a white, active checkbox next to them. The operator clicks on the checkbox after completing that task, and the system logs the operator’s name and the date and time in the relational database. The screen updates by filling in the checkbox and displaying the operator’s initials. Those steps assigned to other employees are grayed out (inaccessible) to the currently logged-in operator, but each operator can see the status of the other employee’s tasks (the system updates sign-offs in real time). When all steps in a procedure have been completed, the procedure is marked as “Done” by placing an “X” in the Done column. This provides a high-level status overview for those wanting to check the progress of the field operations. One benefit of on-line, interactive procedures is that they can be made more context-sensitive. Figure 7 shows an example of how we do this, namely, by displaying live process data right inside a procedure step and allowing outside operators to enter readings directly from the field. This procedure originally required operators to call in tower level readings (over the radio) to the central control room operator to ensure that the control system’s readings of those
Figure 8. Ability for users to enter outside readings from the field using an on-screen keypad.
44
S. Guerlain et al. / Personal information processing systems
Figure 9. A Task Scheduler allows field operators and supervisors to get a sense of all tasks scheduled.
levels were calibrated with the manual readings displayed in the field. With our system, outside operators can now see the live process data on their PIPS device, eliminating the need to ask the central control room operator for this information. If the outside reading is significantly out of range, the user can call up an on-screen data entry keypad (using the “>>” button) to record the outside reading (see figure 8). Eventually, our system could automatically generate a work order to repair the level indicator (although we did not make this link for our field test). The “View Today’s Tasks” option only shows tasks scheduled for the current day and shift. The user can select “Schedule Tasks” (see figure 9) to navigate to different days and shifts to see what is scheduled. Past tasks have presumably been completed, so users can see the initials associated with steps but can no longer change the signoffs; future tasks cannot be signed off either. If logged on as a supervisor or administrator, one can also schedule existing procedures, schedule “simple tasks,” or make one-time-only requests of field operators (such as taking a reading or checking a valve) (see figure 10).
Figure 10. Administrators can schedule new tasks or existing procedures over the web.
S. Guerlain et al. / Personal information processing systems
45
Figure 11. A process data screen allows users to view up to 16 process points at a time, save favorite points, and save favorite groups of points.
The “Review All Tasks” option allows operators to review any procedure entered into the system, not just those that have been scheduled. The user interface is similar to the “View Today’s Tasks” option, except one cannot sign off a procedure that has not been scheduled. The “View Process Data” option (see figure 11) allows the user to select and view any process data point in the refinery (information that can only currently be seen in the central control room or in the shed outside on the unit). A drop-down listbox allows the user to select the process point’s alphanumeric prefix (e.g., F for flow, L for level) and then use an on-screen keypad to enter the process point’s numeric identifier. Up to 16 process points can be displayed at a time. To eliminate the need to enter process point identifiers each time they use the system, users have the ability to save individual points into a “Favorites” list or groups of points into a “Favorite Groups” list. These favorites are specific to each user. The system has navigation buttons similar to most browsers (Back, Forward, and Reload), as well as contextsensitive help (the system displays help relative to the
screen being displayed when the Help button is pressed). We implemented our own navigation buttons because we wanted to maximize screen space, so we removed from view the browser’s default navigation bars and incorporated the features we needed into our own taskbar. Finally, we wrote a separate program, which periodically “pings” the server to see if there is still a good connection. The status is indicated via a small floating window at the top of the screen (not shown). As a user moves out of RF range, or the signal is lost, the status indicator changes from “Good” to “Bad”. Users can change the pinging interval from 1 to 15 seconds. 7. System integration The RF network, server, and system software have been installed and tested on site. The digital wireless LAN has been verified to be fully operational, covering more than 95% of the test area. Effective data rates seen by the user vary, as the communication path back to the main access point may be direct or through a repeater. Packet errors
46
S. Guerlain et al. / Personal information processing systems
due to signal attenuation cause retransmittal of the information and contribute to reductions in effective data rates. Seamless roaming was monitored and verified as the connection between the mobile worker and the access point switched as the mobile device moved around the facility. There are spots where the connection is lost, but the software gracefully re-connects as users move back into RF range. Early tests of the integrated system show that, as expected, the force-joystick mouse on the Eyewand is somewhat difficult to use. Some users are able to use it right away, while others have a hard time controlling the pointing device. One interesting phenomenon is that some people perceive the up/down motion of the pointing device to be counterintuitive. The left/right mapping makes sense to everyone using the device, but psychophysically, some people feel that pushing the mouse toward the top of the Eyewand (toward themselves) should make the cursor go down, whereas for others, it feels “right” for the cursor to go up when pushing the mouse toward themselves (which is the way the mouse is designed by the manufacturer). This difference in perception suggests that the up/down mapping of the cursor should be configurable by the end user while keeping the left/right mapping intact, but this option is not available with this device (since it was designed for laptop devices, not for devices held to the eye).
8. Field test At the beginning of our one-month field test, 25 operators from 3 shift teams went through informal training. Operators were initially trained on the software, using two personal computers that have web access, and then trained on the use of the wearable hardware (changing batteries, starting the Trekker units, putting them on, operating the Eyewand, etc.) Total training took about 30–45 minutes per group of operators (2–5 operators were trained at a time). Operators’ initial reaction to the systems ranged from skepticism to excitement. Roughly one in four operators were excited by the whole system. About 3 out of 4 operators liked the software but weren’t sure of the utility of having the ability to use the software in the field in addition to using the software in the shed. The final 25% remained skeptical. This is a fairly typical percentage of acceptance for such a major socio-technical change. No major design flaws were uncovered in the software. Operators found it easy to use, and liked the ability to personalize the software (see tasks only related to their position, their shift, etc., and to save favorite process data points). The software team made some minor modifications to the software based on operator feedback (such as providing the ability to mark a procedure step as “Not applicable” when a routine procedure cannot be completed due to maintenance). To accommodate this, we added an “N/A” button to each procedure step in the client software
(see figures 6 and 7). This is an example of how using a hardware system with only a mouse-based user input device places added burden on the client software to ensure that on-screen controls exist for any action that might need to be taken. Operators were able to easily learn how to start the Trekker units, change batteries, and put on the systems. However, there are still some challenges with the hardware system, most of which we predicted ahead of time. The Trekkers are clearly too big to be effective as a final solution. The straps on the backpacks were too small for some of the larger operators, and the backpacks took too long to get on and off. Operators were concerned about the weight of the systems, and the risk of not being able to fit up the ladders that have cages around them. Despite these drawbacks, many of the operators were willing to carry the systems around as is, and saw them as a reasonable interim solution until a smaller system could be developed. The Eyewand display was easily seen by most of the operators, except those that needed glasses! Some operators had difficulty learning to use the mouse. Slowing down the mouse on the control panel helped somewhat, but there is still room for improvement on the mouse usability. Finally, some operators did not like looking into a small display with one eye. After training, operators were asked to use the systems on a volunteer basis over the next month. Three Eyewand/Trekker systems were left on site, along with a hardware manual and software manual. The software was also accessible on desktop computers via the corporate intranet. An unplanned power outage interrupted the field test for ten days. In the remaining 20 days, 16 operators used the systems, half of them using the system 1 or 2 times, the other half using them up to 6 times during the field trial. Nine operators voluntarily filled out an extensive survey form at the end of the field trial. Survey respondents were, on average, 37 years old with 9 years of petrochemical operations experience. They worked all shifts and rated their computer experience from Beginner (n = 2) to Intermediate (n = 6) to Advanced (n = 1). Seven operators said they climbed structures while wearing the PIPS system. Problems identified with the hardware included the bulk and weight of the systems (n = 6), having to look at the screen with one eye (n = 4), difficulty using the mouse (n = 3), hard to use with gloves (n = 2), the inability to safely walk around and use the system at the same time (n = 2), losing the RF signal (n = 2), and not having a keyboard (n = 1). When describing what they liked, operators wrote that the system was: “accessible”, “customized”, “versatile”, “user-friendly”, “convenient”, “portable”, and “it saved everything that was entered”. On a scale from 1 to 5 (Strongly Disagree to Strongly Agree) the statement, “I believe this software, if implemented refinery-wide, could improve communication and collaboration”, had a mean rating of 3.6 with a .55 standard deviation. On this same
S. Guerlain et al. / Personal information processing systems
scale, the statement, “I would like this system to do my work” had a mean rating of 3.5 with a 1.51 standard deviation. 9. Conclusion Although challenges remain in designing the right wearable system for this environment, we feel we are approaching a solution that will work in this industry. By designing a smaller, lighter weight, intrinsically safe computer, and adding more field-specific hardware (such as infrared temperature sensors, vibration analyzers, bar-code readers, voice radio communications, and/or a flashlight) and field-specific software (such as more on-line procedures, schematics, and trending), we will have a system that extends digital information to and from the field, enabling more coordinated, real-time communication and collaboration. The design of wearable computers is challenging due to the co-dependence of the software and hardware. In our case, determining software design requirements was challenging when both wearable hardware and RF design decisions had the potential to greatly impact the type of software that should (or could) be developed. Although we tried to design our system to be as open as possible, with a distributed architecture that allowed our PIPS server to access existing as well as new databases, we still find those who request the ability to run existing desktop applications, as is, in the field. We believe that the desktop environment was designed for just that, the desktop, and is not the right paradigm to follow when designing for field operations. Finally, it is noteworthy that in the two years we have been working on this project, the interest of our customer base has been strong and continues to grow. Although efforts to provide a solution for the roving refinery operator continue, no existing system has yet proven itself viable enough to be widely adopted by this industry. We believe that a user-centered approach like the one followed here provides the best chance for packaging these technologies into a usable, successful system. Acknowledgements We would like to acknowledge and thank the NIST Abnormal Situation Management Consortium, which partially funded this project. In particular, we thank the operators at the AMOCO Whiting Refinery who tested the system and gave us feedback on our designs. We gratefully acknowledge the help of Logica, who helped with the industrial design, CAD, and plastic molding of the wearable hardware, casings, and holstering devices. Finally, this work would not have been possible without the technical expertise of many Honeywell employees who contributed to software design and development, RF network design and implementation, hardware design and ergonomics, optics design,
47
and electronics engineering and circuit board design and implementation.
References [1] W. Reinhart, S. Guerlain and R. Whillock, User interface for personal information processing systems: Interim status report, Honeywell Technology Center Technical Report (1996). [2] W. Reinhart, S. Guerlain and R. Whillock, User interface for personal information processing systems: Phase 1 final report, Honeywell Technology Center Technical Report (1996). [3] A. Smailagic and D. Siewiorek, Matching interface design with user tasks. Modalities of interaction with CMU wearable computers, IEEE Personal Communications, IEEE Communications Society 3(1) (1996) 14–25.
Stephanie Guerlain has been a principal research scientist in the User-Centered Design Group at Honeywell Technology since 1995. She has a Ph.D. in cognitive systems engineering from the Ohio State University, and has worked previously at Apple Computer and the MITRE Corporation. Her primary areas of expertise are in the design of decision support systems, making automation understandable and usable, and in supporting teams of people in their work environment. She is a member of ACM, IEEE, and HFES.
Jim C. Lee is a senior principal research scientist in the Information Processing and Displays Department at the Honeywell Technology Center. He joined Honeywell in 1972 with a Masters degree in solid state physics from Cornell, and has worked at several Honeywell divisions and research centers over the intervening years. He has worked in a variety of disciplines ranging from thin optical materials development to space-borne optical sensor system design to terrestrial wearable situational awareness conveyance systems. He is a current member of SID and a past member of SPIE and MRS.
Troy Kopischke was a research scientist in the Information Processing Systems Group at the Honeywell Technology Center for two years. He has a Bachelors degree in electrical engineering from the University of Minnesota. He designed and developed electronic systems for the Technology Center. He is currently director of engineering for Logica Microsystems who provide contract design focusing on embedded hardware and software development for fixed and portable systems. Thomas Romanko has been a senior research scientist in the RF Systems Group at the Honeywell Technology Center for 2 years. He has a Bachelors degree in electrical engineering from the University of Minnesota, and has worked for 12 years with Honeywell in military and commercial avionics development. His present position focuses on wireless LAN development and spread spectrum communications.
48
S. Guerlain et al. / Personal information processing systems Peter Reutiman is a Technology Specialist in the Information Processing Systems section at the Honeywell Technology Center, where he has worked for 20 years. He has gained experience over the years working with human born displays, optical systems, and design of display electronics systems.
Scott A. Nelson is a Technology Group Leader in the Systems and Software Department of the Honeywell Technology Center, where he has worked for 9 years. He received his Ph.D. in applied physics from Cornell University and has worked on electro-optical sensor and human born display systems for the past 6 years. His present position focuses on embedded systems and communications for realtime fault tolerant applications. He is a past member of SID and SPIE.
