MoCCA: A Mobile Communication and Computing ... - CiteSeerX

MoCCA: A Mobile Communication and Computing Architecture Asim Smailagic, Dan Siewiorek, Len Bass, Bob Iannucci*, Anton Dahbura*, Steve Eddleston*, Bob Hanson*, Ed Chang* {asim, dps, ljb}@cs.cmu.edu; {bob, atd, seddleston, hanson, changed}@crl.dec.com Institute for Complex Engineered Systems Carnegie Mellon University, Pittsburgh, PA 15213 *Compaq, Cambridge Research Lab, Cambridge, MA 02139

Abstract In this paper we present an integrated computing system designed to help increase the efficiency of mobile workers, specifically field service engineers. Our solution, a Mobile Communications and Computing Architecture (MoCCA), consists of both a futuristic award-winning concept design and a first-generation working prototype. The prototype has support for collaborative multimedia: on-the-move networking for high-tech equipment maintenance using voice, video clips, and access to maintenance databases. We describe the user interface, software, and hardware architectures of our prototype. The hardware architecture uses a multi-tier networking scheme to trade off a small lightweight client and high computation power and battery life. Finally, we present lessons learned from user tests in applying a novel mobile computing architecture to a complex real-world task.

1. Introduction The use of current mobile computing hardware has grown at a rate of about 15% per year, with no signs of slowdown in the near future [1]. A large fraction of those devices are used in vertical applications such as sales, healthcare, and field service. In those applications, standard mobile computing devices such as laptops are customized with software to become useful industryspecific tools. For example, some systems integration companies advertise total solutions for vertical markets without displaying much innovation in mobile devices. Other companies introduce cycles of innovative end-user products for the horizontal market, e.g. the Palm and WinCE devices. There is, however, significantly less work done on a systems level that combines multiple devices and functions synergistically. Thus there is a gap in the mobile computing space: total connectivity solutions for vertical applications that include customized novel end-user devices and applications.

To explore this area further, we designed the Mobile Communication and Computing Architecture (MoCCA). The vision of MoCCA was to create a very portable integrated system supporting a group of geographically distributed mobile workers. We chose field service as our specific test application because of our ties to Digital/Compaq’s field service organization. Our goal was to design a system that would increase the productivity of the field service engineer (FSE) and to replace many of the gadgets currently carried or worn.

2. Field Evaluations After settling on the specific task of FSE, we began field evaluations to formally rethink how communications and computing should be designed for mobile workers. Our goal was to create a workflow model that would formulate a basis for the MoCCA device requirements. To begin this process, we interviewed and shadowed FSEs through various actual work scenarios. We then condensed our experience into the following four-stage model as shown in Figure 1 below. We found the following complexities in the FSE work environment delineatead by this model. For the first stage of accepting a new call, the FSE would often be required to balance multiple calls and go through a complex negotiating process with the customers and main office in order to set a ordered schedule of call processing. Since the FSE could not see the overall workload, there was a large degree of unpredictability in the call response times. In addition, many problem reports were incomplete, hampering the FSE’s ability to effectively prepare for calls in the second stage. Upon arriving at the customer site (stage 3), the FSE is limited to voice communication via phone or two-way radio. Some customer sites will provide landline telephone, but others cannot. In either case,

FSE’s would prefer to be self-sufficient for their communications needs to appear more in control of the situations. As for the current cell phones and two-way radios, the wireless technology is not yet fully mature and has trouble reaching into some buildings. Finally, the fourth stage of closing the call has difficulties both in entering and disseminating the information. Often the full experience is not able to be captured in a form that can be transmitted to the other FSEs in the organization. The existing databases, like much of the documentation in the computer industry, is often full of unhelpful or outdated information. As a result, when an FSE encounters an unfamiliar situation, he turns to an informal network of other FSE’s to find someone who has experience with this particular problem. A better system of recording experience would aid the next FSE in handling the same problem without resorting to human intervention. Thus we found the following three key conditions that drive the work practice: •

• •

Planning: The FSE wants to work on the right thing and have a better outlook on the upcoming schedule. This requires a better means of coordination with the other FSEs and the dispatch office. Preparation: The FSE wants better information to know more about a call request before arriving at the customer site. Professional Image: The FSE wants to appear proficient and capable of handling the problem. The FSE does not want to rely on the customer’s phone, computer system, or documentation. Furthermore, the FSE wants to look like the other employees at

the customer site. Early inquiries into novel wearable computing solutions with head-mounted displays were met with strong resistance. From these conditions we were able to arrive at a set of design requirements. The design had to support existing practices and positive changes in those practices. In addition, the device was to be used in multiple settings. We found that the FSE is at the dispatch office about 30% of the time, on the road another 30%, and the remainder of the time at customer sites. Ideally the device would have different modes of entering and retrieving information that would account for all three of those locales. Thus the fundamental challenge was to provide a system that allows the FSEs to access information and advice from other FSEs while on customer sites and while commuting between sites. The final design wish list was as follows: • • •

•

The system should have all of the functionality of a laptop computer including a large color display and an operational cycle of at least eight hours. The system should be very light, preferably less than one pound in weight. The system should provide both synchronous and asynchronous communication. The former is used to maintain contact with other FSE team members, using the telephone metaphor. The latter is more of the computer or web browser model, in which information can be stored and retrieved at the FSE’s convenience. The system should have access to several legacy databases across different corporate computing systems. The most frequently used databases are textual-oriented. On rare occasions, access to graphical databases is required.

Databases

2. Prepare

4. Document and close call

Customer Site

Research Obtain Parts Call Customer Travel

3. Solve the problem

Figure 1: FSE Work Process Model

1. Accept new call

3. Research Issues

4. Concept Design

Given the design constraints and considerations of FSE work, we chose to address three primary research issues in MoCCA:

Our team worked with Compaq’s Industrial Design department and Fitch Inc. to create a concept design that could be produced three to five years in the future. The end result is the 4-inch wearable computer shown in Figure 2. It has an ergonomic folding handle and a pair of folding Organic LED (OLED) touchscreens; this provides a large display size in a small package. The integrated camera, microphone, and speaker allow videoconferencing or capturing pictures or video clips. Finally, wireless access provides phone connectivity, data transmission, and location awareness.

•

Wearable, multi-tier design The main design issue was to tradeoff between high functionality (wireless access, large screen, long battery) and low obtrusiveness (size and weight). We addressed this with a multi-tier design that split the core functionality between a small wearable client and a larger, more powerful base unit included in the FSE toolkit.

•

Voice as primary medium One of the primary design requirements was to keep the current ability of contacting other team members via phone or two-way radio. MoCCA was allowed to augment but not replace this existing feature. In addition, we wished to explore the use of voice as a control system to leave the users hands free.

•

Hybrid multi-modal interaction The final issue was to explore the space of using a combination of voice, text, and graphics to provide a richer mobile interaction and more functionality.

Previous work at CMU on wearable computers [2-5] provided background for this project. Collaboration using portable computers has been reported in [6-8].

Because of the folding handle and screens, the MoCCA concept design could be used in a number of different positions. In addition to being held like a standard palmtop computer, it could be stood on a flat surface like a picture frame or worn around the neck to free one’s hands, as shown in Figure 3. This concept design was chosen for the 1998 Business Week Design Exploration award [9]. This MoCCA concept design showed how harnessing a powerful, wearable communications processor to high-speed voice and data networks could provide the following functions for the FSE of the future. First, MoCCA could connect the user to one or more team members or customers via voice and video. Second, the device provided voice or touch-activated mailbox management for voicemails, e-mail, and video mail. Third, back-end servers could handle information and data queries to remote databases. And finally, the MoCCA device could replace the scheduling and phone list functions of a standard PDA.

.

Figure 2: MoCCA Concept Design

Figure 3: Handsfree usage

Figure 5 is a view of the functional system architecture. The software architecture uses a thin client approach to minimize the amount of software on the system by exploiting web-browsing technology and wireless CDPD Internet connection to communicate with a server. The satellite unit is not running the browser; it is merely displaying whatever is currently on the base unit display.

5. Overview of System Components, Use and Design Although the concept design was compelling, it was also not feasible to build in 1996. Figure 4 depicts the components of the prototype MoCCA system we actually built, with a field service engineer shown in the center of the figure:

There are six buttons defined for the user interface. The Bboard button provides access to a phone-based voice bulletin board where FSEs may asynchronously collaborate to solve problems. The Calls button accesses the summary of active field service calls for the engineer. The phone button invokes an auto-dialer keypad. The FSE button brings up a directory of FSEs, and the Availability button shows their current status. The Pager button accesses the list of current Pager messages. The FSE directory, Pager message list, Calls list, and Availability form are all web pages, generated automatically from various field service databases.

1. A base unit, about the size of a small laptop computer which is connected to a remote server (located at the home office) wirelessly through a CDPD connection. 2. A cellular phone associated with the base unit and tethered to it through a PCMCIA port. The cellular phone communicates wirelessly with the local cellular provider and thus has access to the telephone network. 3. The FSE holds a smaller satellite unit that is connected to the base unit. This link allows the satellite to show the contents of the base unit screen and to link its keyboard input directly to the base unit keyboard. 4. The FSE wears a microphone and headset that are wirelessly linked to the cellular phone.

FSE with Satellite Unit and Phone Headset

CDPD Provider

Cellular Provider

Wireless Connection Wireless Connection

Base Unit RS232 Cellular Phone

Dispatcher

Standard Phone Line Connection

TCP/IP Connection

Server Unit

Carnegie University Figure 4:Mellon MoCCA Prototype System Architecture

MoCCA

Bboard

Calls

Phone

FSE

Availability

Satellite Unit with PC Anywhere software

Pager

submit submit

Base Unit with Netscape Browser Software

CLIENT SERVER

CDPD Internet Access

Contracts

Customers

Calls

FIELD SERVICE DATABASE Carnegie Mellon University

Figure 5: Data Architecture

The legacy databases and access software reside on the server machine located at the home office. It contains a database of field service information that was designed and customized to the specific needs of Field Service Engineers. When the FSE presses one of the user interface buttons or link on one of the browser web pages, a request is sent to software developed for the MoCCA unit to initiate a query on the Field Service Database. The results from the query are dynamically formatted into a web page. Then all the appropriate links are made to enable related queries and the page is passed across the CDPD network to the client machine that displays the web page. This approach is more flexible than having a set of pre-made web pages. The web pages are up-to-date with the data in the database and allow very precise queries to be performed. In addition, monitor software residing on the server can watch certain directories and when data changes, notify the FSEs browser to change the color of one of the user interface buttons to alert them to re-run the query.

6. User Interface A summary of the integrated user interface software is presented in Figure 6. The Field Service Engineer Call List is the central screen and all other screens can be accessed following hypertext links or the screen buttons. From the Call List screen, the user can select a primary function to be performed, such as database query (Call List) or messages via a pager. Depending on the primary

Service Log Entries

FSEs

Maintained Items

Parts

Web page generation software

MoCCA

function selected, subsequent secondary screens will display more detailed information. In the case of pager messages, the secondary screens allow the user to enter new information. Consider the following typical usage scenario of MoCCA. The FSE checks the current status and the status of other FSEs by clicking on the “FSE Information” button. This leads to a web page (Figure 7a), generated from the MoCCA database, listing the names of all the FSEs, their cell phone numbers, their email addresses, and their current status. The FSE changes his status from “Off Duty” to “Available” to let others know that he can be reached by cell phone. This is done by clicking on the “Availability” button at the top of the screen, leading to the Availability Selection page, Figure 6. Clicking on the “Available” button leads back to the FSE Information page. To check the list of calls assigned to the FSE, he clicks on the “Calls” button at the top of the screen, and brings up the “Call List” screen, Figure 7b. The page is assembled from a database query of the calls assigned to the FSE. It filters the list of all calls to only display those with an “Open” status. The table lists each call with the customer name, the time the call was received, the service contract, the contact person, their phone number, and a short description of the problem. Each underlined entry leads to further information about that field. If the FSE wants to review the assigned calls, and the previous problems at a site, he clicks on the “Call Query” button, which brings up the “Call List Queries” page. To get more

FSE Information

Pager Messages

Cellphone access to Voice BBoard

Dialer Availability Selection 1. 2. 3. 4.

Make Topic List Topic Add Message Delete Topic

Sending Pager Messages

Detailed Call Information Call List

Tip Filtering Call List Queries Call Logging

Tips

Figure 6: Summary of the integrated user interface software

details on a particular call, the FSE clicks on the description of the problem, showing the “Detailed Call List” screen, Figure 7b. The page is assembled from a database query of the calls assigned to the FSE. It filters the list of all calls to only display those with an “Open” status. The table lists each call with the customer name, the time the call was received, the service contract, the contact person, their phone number, and a short description of the problem. Each underlined entry leads to further information about that field. If the FSE wants to review the assigned calls, and the previous problems at a site, he clicks on the “Call Query” button, which brings up the “Call List Queries” page. To get more details on a particular call, the FSE clicks on the description of the problem, showing the “Detailed Call Information” list. By clicking on the “Service Log” button, the FSE can review the Service Log entries associated with that call, leading to the “Call Logging” list. If there is a “Tip” recorded with information, the FSE can examine its contents. After reviewing the call history, he can look at the current “Call List” again. The inclusion of a small satellite unit into the system made an impact on the user interface design. This effectively reduced the amount of information that could be displayed to the user and meant that two separate

interfaces would have to be developed, resulting in a simpler user interface for the satellite. Earlier simplifications had been driven more by the cost of downloading screens over CDPD than by the size. The Cassiopeia has a screen size of 2.5” x 4.75”. The Cassiopeia measures 480 x 240 pixels to the base unit’s 640 x 480 pixels. This difference between the two screen resolutions is significant because the software used to send information from the base unit display to the satellite unit (PC Anywhere under Windows CE) works merely as a static viewing port. The smaller screen does not show the entire contents of the base unit screen, but rather, a section of it equal to the size of the smaller screen. Also note that the Windows CE software and the Netscape browser windows use screen real estate, leaving a very tiny area for user screen interface controls and information. As the PC Anywhere software provides a scroll bar, the satellite viewing port can be moved to other locations on the base unit screen. However, having to scroll the screen up and down can be annoying to users. Thus the first screens are developed in a manner that made it possible to avoid scrolling.

Notification Managers are implemented as custom Java applets. The server also contains a hardware component, the Dialogic board, with associated software that controls the voice bulletin board system and dialing in.

Figure 7a. Sample Screen Image for FSE Information

Figures 9 and 10 depict the base unit components and the satellite unit hardware. The base unit includes a 586 133MHz processor, running the Windows 95 operating system. There are two PCMCIA slots on the base unit: one is occupied by the AirCard CDPD/Modem, and another by the modem dialing to the cell phone. Finally, an RF transceiver links cell phone and the headset. Client

Base

Satellite OTS Cassiopeia

pcAnywhere OTS Software

Server DBM OTS Poet DB (Java) Customized Data Customized Schema

Web Server and Servlets Custom Java Code

Data: - FSE Info - Calls - Tips - Parts - Customers - Contact

pcAnywhere OTS Software Browser Netscape 3.0

Figure 7b. Sample Screen Image for Call List Pages

7. Software and Hardware Architecture The architecture of the MoCCA software is depicted in Figure 8. The architecture can be broken into three different subsystems: Client, Base and Server. The communication among the subsystems employs different mechanisms. The Client communicates with the Base unit using a serial connection. The Base communicates with the server by TCP/IP over variety of media. The software was divided into functions to facilitate parallel development. The Client appears as a window into the Base. This functionality was achieved by using an off the shelf product called PC Anywhere. Netscape Navigator browser runs on the Base unit and can view the web pages generated by the Server. The browser retrieves the information from the Notification Manager, and displays it as the first page. The Notification Manager informs the FSE of a newly arrived event and is represented by a button. The Server contains two data types, the first contains FSE and customer data, the second contains the voice bulletin board data. The Server contains a database manager and a voice database manager, which are accessed via servlet calls. A Java database called Poet was chosen. Poet is a "cross-platform" database supporting both C and Java schemas, and allows for easy integration of different software components. The Notification Manager server informs the Notification Manager on the Base of changes to the databases. Both

Notification Manager Custom Java Code

Phone Dialer OTS Software Notification Manager Custom Java Code

Cell Phone OTS Consumer Model

Voice Board Custom C++ Code

Dialogic Card OTS Hardware

Figure 8: Software Architecture Carnegie Mellon University

MoCCA

Server

Voice Line Cellular

In Tool Bag CDPD

Cell Phone

On User

RF Transceiver

RF

Head Set 1.8” IDE Hard Drive LCD Screen

2 Type II PCMCIA Slots EIDE Controller Video Adapter

Touch Screen

Type II PCMCIA Slot For Modem

Serial Port

Base Unit Serial Port

Figure 9: System Architecture

Carnegie Mellon University

Cassiopeia RS-232

Serial Port

MoCCA

8. Conclusions In this paper we posed the research problem of designing an integrated computing system that would help increase the efficiency of mobile workers, specifically field service engineers. Our solution, a

Video LCD Panel

Serial TouchScreen Serial Satellite

Antenna

CPU Board - 586 - 133MHz, 16MB - Video Controller (34 pin) - 2 Serial, 1 Parellel, IDE PC/104 Bus PCMCIA Controller 2 Slots: Type I, II, or III PC/104 Bus PCMCIA Controller 2 Slots: Type I, II, or III

Parallel

RF to Headset CDPD, Cellular Modem -2 Type II - Data Comm Modem - 1 Type II

[1] P. Redman, “The Mobile Enterprise”, Mobile Computing and Communications 1999 Annual Deployment Guide, January, 1999

Phone Jack

Phone Jack

Hard Drive Voice Cellular Phone

Figure 10: Base Unit Hardware

Carnegie Mellon University

10. References

MoCCA

Mobile Communications and Computing Architecture (MoCCA), consisted of both a futuristic award-winning concept design and a first-generation working prototype. The prototype had support for collaborative multimedia: on-the-move networking for high-tech equipment maintenance using voice, video clips, and access to maintenance databases. One of the first lessons we learned that was the appearance of a wearable computer is a primary consideration for its acceptance in a mainstream application. Small devices that make the transition from tool to accessory or clothing are judged much more strictly on aesthetic grounds. Furthermore, there was strong resistance to the cyborg or robotic look. Since the MoCCA prototype was built in 1996, there have been many advancements in display technology [10]. But there is still a long way to go before production and social acceptance of unobtrusive wearable displays. Through user tests, we found that the combination of voice and data resulted in a richer interaction useful for field service engineers. The ability to choose the data type of interaction was critical in providing flexibility of usage situations. Finally, our prototype multi-tier network architecture demonstrated a viable method of trading off a small lightweight client with high processing power and battery life.

9. Acknowledgements The research reported in this paper is supported by Compaq Computer Corporation, the DARPA, and the Institute for Complex Engineered Systems at Carnegie Mellon University. Fitch Inc. design studio also contributed to the final appearance of the MoCCA prototype. Finally, we would like to thank Chuck Kukla for designing and conducting the user field studies, and Jane Siegel for her help and insight. The field tests were conducted at Compaq’s facilities in Forest Hills near Pittsburgh, PA, and San Jose, CA.

[2] A. Smailagic, D. P. Siewiorek, “The CMU Mobile Computers: A New Generation of Computer Systems”, Proc. IEEE COMPCON 94, IEEE Computer Society Press, pp. 467-473, February 1994 [3] A. Smailagic, “ISAAC: A Voice Activated Speech Response System for Wearable Computers”, Proc. IEEE International Conference on Wearable Computers, Cambridge MA, October 1997 [4] A. Smailagic, “An Evaluation of CMU AudioCentric Wearable Computers”, Journal on Mobile Networks and Applications, ACM and Baltzer Science Publishers, 1999 [5] D. P. Siewiorek, A. Smailagic, et. al., “Adtranz: A Mobile Computing System for Maintenance and Collaboration”, IEEE International Conference on Wearable Computers, Pittsburgh, PA, October, 1998 [6] M. Billinghurst, S. Weghorst, T. Furness III, “Wearable Computer for Three Dimensional CSCW”, First International Symposium on Wearable Computers, Cambridge, MA, October 1997 [7] J. Rekimoto, “Transvision: A Hand-held Augmented Reality System for Collaborative Design.”, Proceeding of Virtual Systems and Multimedia - 1996, Gifu, Japan, September, 1996 [8] M. Bauer, T. Heiber, G. Kortuem, Z. Segall, “A Collaborative Wearable System with Remote Sensing”, Second International Symposium on Wearable Computers, Pittsburgh, PA October 1998 [9] “Annual Design Awards: Cell Phone Meets Laptop”, Business Week, May 25, 1998 [10] Wearable Computing Displays list at MIT: http://lcs.www.media.mit.edu/projects/wearables/display .html