MANUFACTURING TECHNICIAN'S USER INTERFACE:

TAMING THE SAVAGE UI BEAST

 

Shannon Nelson

Intel Corporation, Portland Technology Development

 

 

 

 

 

ABSTRACT:  Over the past few years Intel has added more and more computer based automation to its factories.  As the automation systems have evolved, more and more functionality has been incorporated together, using a variety of User Interfaces to access the underlying data.  For example, some applications use commercial products such as Workstream, others use Intel-developed station controllers, still others use other methods. 

 

This forces the manufacturing technician (MT) to change interface styles for each different step in the processing.  None of the current UI's are coordinated, thus making the interactions between systems problematic, slow, and error-prone.  This also makes training more difficult, time consuming, and costly.  Add to this the various and changing interface platforms, including VMS, UNIX Curses, X Windows, and Microsoft Windows, and solutions to the UI problem get even more complex.

 

In our 1995 Automation Usage Study (see previous paper) we measured the cycle-time impact of Automation systems from the MT’s perspective.  With this as a start, we started collecting functionality into groups and prototyping screens based on those groups.  User interviews were conducted where these prototypes were further refined and reviewed. 

 

The resulting product is MTUI, the Manufacturing Technician’s User Interface. Using Java, we've developed a flexible, portable framework into which "function cards" can be plugged.  These function cards group and present the controls and data that are needed for processing WIP in the factory. In this paper, we present the overall architecture of MTUI  and discuss the technical challenges associated with implementing the architecture. We revisit the cycle-time conclusions from the 1995 usage study and conclude with the cycle-time benefits realized by the use of MTUI.

 

An Especially Tricky Problem

User Interfaces are an especially tricky problem.  It seems that everyone “knows” how UI’s should work, and yet no one can agree on the details. Microsoft’s Windows 95 sets up the whole paradigm for how to use the computer keyboard and mouse, and most of the Microsoft programs published since Win95 was released following the same guidelines.  However, many other programs from other publishers don’t follow all the guidelines, but have their own variations.  Add to that all the programs that were written for DOS or Windows 3.x, and you end up with quite a few different styles.  For example, the Find command for finding a particular word is usually in the “Edit” menu, but there are several different keyboard accelerators that do the same function depending on what application you are in: <Ctrl+F>, <F2>, <Alt-F3>.  Also, different programs will use various color schemes, icons and fonts for displaying information, like white Courier font on black, white on blue, black Times-Roman on gray,

 

As Intel’s manufacturing software suite has grown over the past few years, it has proven no different. As the automation systems have evolved, more and more functionality has been incorporated with several different ways to access the underlying data. There is no standard user interface for processing WIP and maintaining the fab equipment and the developers have come up with quite an array of different UI’s.  Some of this comes from the various hardware platforms on which the manufacturing software has been developed and delivered.  The variations run the gamut from ASCII menuing screens on VAX/VMS to ASCII/Curses or X/Motif on UNIX to Win 3.51 applications.  All have their importance to the manufacturing system, yet few seem to be coordinated with each other or to use similar keystrokes or commands.

 

All this variation causes several problems for training, maintenance, and performance enhancements in the factories.  Learning does not transfer from one application to another, so re-training is necessary.  This forces the Manufacturing Technician (MT) to change interface styles for each different step in the processing.  None of the current UI’s were coordinated, thus making the interactions between systems problematic, slow, and error-prone.

 

 

 

Figure 1. Taming the savage UI

Automation Architecture

The Intel automation systems have developed through the years from the original central VAX and VT100 terminal system.  A few “client” systems that talk to the process tools and the central VAX were added as station control systems to help the MT’s run the process tools.  Soon more servers were added to get more information to and from the station controllers.

 

Several networking protocols are used for moving the information from system to system.  We started out with simple serial connections, followed with DECnet protocols, and now primarily TCP protocols are used.  On top of TCP we use both request-reply and publish-subscribe mechanisms to make data and services available on the network.

 

In planning our next process generation we decided to consolidate and simplify parts of our automation system user interface as part of our migration from a chaotic client-server network to a more controlled three-tier architecture.  A three tier architecture separates the UI layer from the Logic layer and the Logic layer from the Data.  The intent is to have systems tuned to their specific task, and to set up a clean communication interface between them such that no layer is directly tied to another.  This gives flexibility - the UI doesn’t have to change when a new database is used, nor when logic services are migrated from one server to another.

 

 

Figure 2. Three Tier Architecture

 

As part of migrating the automation system to the three-tier architecture, we wanted to make the User Interface more consistent and easier to use.  In the process, there were many things to consider: the hardware platforms available for presentation, the likely future platforms, the existing UI software, and the new anticipated software capabilities.

Presentation HardwareThe remaining sections provide details for the internals of the MTUI.  These sections are meant to guide the developers of MTUI in building the product.Presentation Hardware

The primary User Interface hardware in existing fabs is the X-Terminal driven by UNIX systems, and secondary are Windows and Windows NT based systems.  In the near future, NT will likely replace the X-Terminal+UNIX combination as a more affordable commodity platform.  The primary UI hardware for office systems is Windows NT.

 

Automation systems are also frequently accessed via modem for remote support by both fab and automation engineers. Home systems are typically a mix between standalone X-Terminals, Windows 3.x, Win95, and WinNT computers, with a few VT terminals thrown in for good measure.

 

Both in and out of fab, the hardware set includes a graphics screen, keyboard and mouse/trackball. There is support on the platform for straight ASCII terminal emulation for logging into VAX/VMS systems.

Application Software

The Presentation layer of existing applications are a mix of several different User Interface styles and access paradigms.  Some current attributes include:

 

·        X-Windows for newer automation applications, with dis-similar window styles

·        MS-Windows UI on desktop workstations and some fab workstations

·        ReGIS and Sixel graphics to view output from several older VMS-based Engineering Analysis tools

·        ASCII-based menu-driven WIP tracking system with several embedded capabilities

·        Other standalone ASCII based applications with different command structures

·        Emulators used to access VMS ASCII-based displays from X and MS-Windows workstations

·        Paper notes taped to the walls

 

The current user interfaces are a combination of systems that have little to no coherency.  These user interfaces are found both in and out of the fab.  Many were first designed as standalone applications and only later added to the automation system.  Some  were built by individuals and organizations within Intel, some by contractors from outside.  Most do not follow the separation requirements of the 3-Tiered architecture.  They look different, use different colors, employ different GUI components, and many use different keystrokes for similar functions.

Usage Study

In the previous paper, keystrokes, mouse clicks, screens, and elapsed time were counted for many different operators at many different steps along the manufacturing process in order to measure the effort used in processing WIP with our automation system.  In this study we found that much time and effort was spent going through many superfluous screens to perform simple tasks such as selecting WIP to be processed.  To get through this high number of screens users often simply memorized required keystrokes and did not actually read the screens.  We also found that the users were able to process their tasks faster if they could keep their hands on the keyboard, rather than moving them back and forth from the keyboard to use the mouse.

Other UI Research

Much literature exists on how to build user interfaces, and there are many examples of both good and bad products.  We spent time going through some of these materials and came up with a couple of standards documents that we found useful.

 

One of the outputs of research into station and cell control applications at SEMATECH was the SCC User-Interface Style Guide 1.0, document #92061179A-ENG, August 21, 1992.  This document had the greatest influence on our final result, in part because it talked directly to our situation.

 

Another book that we found interesting was Guidelines for Designing User Interface Software from The Mitre Corporation, August 1986.  This was prepared for the U.S Department of Commerce National Technical Information Service.

 

Since the MT’s are most accustomed to the applications that they use in the office and at home, we also took a look at these to see what worked and what didn’t.  The result is that even for a multi-platform product, there is a lot of influence from the Win95 interface and other Microsoft applications.  Again, there is good and bad to choose from, but here is where many examples and directions can be taken.

Requirements

Starting with some initial requirements gleaned from the issues above, we began building a series of interface prototypes in Visual Basic, each of which was used as a tool for user interviews in order to further refine and discover detailed requirements.  Information from each round of interviews was fed back into the prototype for more interviews.

 

We also searched through the existing application documentation for the requirements that they addressed.  We felt there was significant requirements gathering work represented that should not be lost.  We found many application specific requirements as well as some general UI requirements.

 

In all, we collected well over 200 requirements, many application specific and many more general UI oriented.  We also found several requirements which were potentially in conflict - in these cases we’ve attempted to find common ground between them and find ways to satisfy the real need behind both.  We also accepted early on that, especially with something as deeply personal as UI preferences go, we will never be able to completely satisfy everyone.

 

The more general requirements include:

 

Fab information must be available outside the fab.

Analysis of information can happen both inside and outside of the fab; this allows for fewer people in the clean environment.

 

Existing X-Terminals and UNIX infrastructure in the fab must be supported.

Replacing the hundreds of stations already in place is not economically feasible.

 

PC-based office and multimedia applications must be supported in the fab.

Popular PC tools are being used to maintain fab information.

 

UI needs to be flexible.

Different fab operational areas have different UI needs.

 

UI processing should happen on a distributed presentation client platform.

This allows offloading the UI work from the central servers and offers the potential of using many less expensive “commodity” platforms.

 

Industry standard UI paradigms must be used.

This increases application integration, simplifies the UI, and reduces the cost of training.

 

Keystroke and screen counts must be reduced.

Interactions must be available via simple keystrokes; UI must display on one screen a summary of all information needed to process a lot, and allow drill-down access for detail.

 

The UI must have clear visual cues for equipment / WIP changes.

Recognizable symbols must be available in addition to color cues for quick assimilation of data and to be useful for color-blind operators.

 

The UI must keep information fresh and up-to-date.

Information must be updated often enough to assure valid data - within 3 seconds of a change, plus or minus 2 seconds.

 

Design Overview

From the prototypes and the requirements, we developed the Manufacturing Technician’s User Interface, or MTUI.  This is the User Interface at each individual tool in the factory.  It embodies the original Station Control application for the process tools and is extended to include more general factory functions.  Instead of requiring a separate VAX terminal emulator to log into the WIP tracking system, an X-based menu bar for login and access to applications, and other systems for additional information (WIP scheduling, tool performance tracking, etc.), these functions are brought together into the MTUI Framework.  For portability to multiple OS platforms, this framework is written as a Java application.

 

Many of the factory services were already available via a client-server type request/reply messaging protocol.  We added new servers and messages for other services and made better use of information available via the publish/subscribe communications.  MTUI also uses a World Wide Web browser to access a wide variety of documentation which was once on paper in the fab but is now online electronic documentation.

MTUI Framework

The MTUI Framework is the screen layout that collects and coordinates the menus, buttons, dialogs, and function cards that make up the MTUI.  The function cards are plug-in modules that combine related WIP processing functions and extend the capabilities of the MTUI.  The MTUI Framework sets up the services needed by the function cards for processing user requests and handling automation system interactions.

 

Basic Screen Layout. The framework enforces standard keystrokes as shown in Table 1.  When the user types these keystrokes they are given to the currently selected function card for processing, except for the < Ctrl >-_ keys.  The <Ctrl>-_ keys are used by the framework for various general functions such as selecting which function card to view.

 

 

 

Figure 3. MTUI Framework

 

 

Key

Meaning

 

Key

Meaning

F1

Help

 

Escape

Cancel dialogs

F2

Refresh Dispatch List

 

Tab

Traverse screen widgets

F3

Introduce Lot

 

Shift-Tab

Reverse screen traversal

F4

Introduce Monitor

 

< Ctrl >-L

Login

F5

Introduce Experiment

 

< Ctrl >-E

Select entity in status bar

F6

Move Out Batch

 

< Ctrl >-T

Select function card tab

F7

      (tbd)

 

< Ctrl >-Z

Zoom message display

F8

      (tbd)

 

< Ctrl >-C

Copy to clipboard

F9

Lot Status Detail

 

< Ctrl >-X

Cut to clipboard

F10

      (tbd)

 

< Ctrl >-V

Paste from clipboard

 

Table 1. Keystroke meanings

 

Menus and Toolbar.  A simple menu at the top gives access to basic MTUI commands including a web-based help facility.  The tool bar below the menus offers a quick way to kick off selected programs.  MTUI launches a program in a separate process by executing a command in the runtime environment.  These are configured once for the whole factory in order to keep the UI similar from station to station.  However, a small amount of personalization is possible for specific groups of stations if necessary.

Entity Monitoring.  A status bar on the left of the screen displays current status of selected factory tools, or “entities”, that MTUI is monitoring.  These show a brief indicator of runtime status of the entities driven from information published dynamically.  Standard colors are used to indicate status.  The colors used are shown in Table 2:

 

 

Color

Meaning

Green

Okay (running)

Yellow

MT intervention required (e.g. Query dialog waiting for an answer)

Red

Stopped - cannot process WIP

White

Off-line (PM, upgrade etc.)

Green flashing

Tool “idle”- needs WIP

 

Table 2. Entity Monitoring Colors

 

Message Display.  A text box at the bottom of the framework prints important messages from MTUI and client applications and can be opened into a large display with a button off to the right.  The messages are initially blue, and when the user clicks on the message to indicate that it has been read, or zooms the message box, the message text color changes to black.

Function Card Manager.  In the middle of the screen is the space for the plug-in function cards, selectable by tabs at the bottom of the function card space.  The function card manager loads in the configured cards and organizes them into the tab panel.  When a tab is selected the manager hides the current card and shows the selected one.

Status Bar.  A status bar at the bottom of the window gives the current time and date, the host computer and display being used, as well as the currently logged-in user.

Function Cards

The MTUI Framework collects together a set of “function cards” that are used as “plug-in” modules that implement a user interface to a specific collection of functions.  For example, there will be one function card for the Station Controller interface and another for the Lot Dispatch functions.  The MTUI is extensible by “plugging in” new Function Cards to the MTUI framework without having to re-engineer the MTUI application.

 

The function cards are decendents of a class that implements the basics of a function card with a blank UI.  Function card developers are expected to use its methods to access the rest of the MTUI facilities.  Furthermore, it is a subclass of the Java applet which will allow the function cards to have a migration path into a browser-based viewer in the future.

Lot Dispatch.  AMHSThe Lot DispatchAMHS function card provides access to the WIP movement and scheduling systems.  The primary view is of the WIP schedule list generated by a central scheduling system.  The card includes action buttons for getting and storing lots from the WIP stockers.

need StoreLot dialog

Entity Status.  The Entity Status function card will provides a view to the current entity status values and the entity history.  In the future, equipment based preventive maintenance function will be added for tool management.

need log event dialog

Lot Status.  Lot status can be viewed in a dialog by selecting a lot from the Lot Dispatch list.  Information available in this view comes from several different systems, including the central WIP tracking, WIP movement, and experiment tracking systems (ICATS).  Access to special processing instructions and other lot specific information is provided.  Some of the detailed processing instructions are available via the web-based documentation system.

Station Controller.  The Station Controller user interface controls the fab tools that process the lots.  It displays the entity’s run status, the current recipe if running, the lots currently in process or done, any alarms and the appropriate action buttons.  The station controller card can control and monitor several entities when necessary, which allows for clustering of tools to one user interface station.  This allows savings by using fewer CRT’s and less of the expensive cleanroom space.

 

As an example of the power of a three-tier architecture, the Station Controller user interface currently works with two different Station Controller systems.  The same UI can talk to two different Logic engines to get the same results, and the user doesn’t need to be retrained to use a new system.

User Security

To handle operational security, the requirements are split into two primary functions: authentication and authorization.  The former is the normal username/password scheme, and the latter is a way of knowing who has the authority to perform certain functions.

 

When a person is logged into MTUI, a database is queried for that persons authorization tokens.  The list of tokens represents what functions the user can perform, and are specific to each different application.  They can be grouped into several “roles” that a user might play in the factory, such as “general user” or “tool administrator”.  The buttons and menu items on MTUI are then enabled or disabled as appropriate for the user’s list of tokens.  A few functions are available with no login.  Once logged in, however, the MT will have access to more of the functions in MTUI such as logging events in the EntityStatus function card and manipulating information for directing WIP processing. 

 

We have both a VMS and an NT domain login name systems that users may be a part of.  In order for both types of users to access the system, MTUI has a login prompt that can select VMS or NT domain login.  MTUI then sends the username/password to either a VMS or NT service that verifies them.  The username is then used as a key to the authorization database, which knows both the VMS and NT usernames of the users.

 

In order to reduce the number of logins and keystrokes performed by the MT, the currently logged-in user name is made available to other applications that need to know who is logged into the station.  When other applications are launched from MTUI’s toolbar, they can be given the current username on their command line, and they can assume that this person has logged in through MTUI.  They can then get their specific authorization tokens for that user if needed.

Java

The Java™ programming and runtime environments are used to make MTUI portable between the X and NT environments.  This permits developers to build the application in using the many development tools available on NT while delivering a product for both X Windows and NT.  In addition, the Java “applet” concept is used as the basis of the function cards, which allows for easier stand-alone development of the function cards before bringing them into MTUI.

Web Browser

As part of Intel’s thrust into using the Intranet for distributing information, World Wide Web technology is used to publish documentation both inside and outside of the fab.  This includes operational specifications, Material Safety Data Sheets, personnel phone directory, vendor reference materials, training and help guides.  The Web Browser is part of the individual station UI in conjunction with MTUI.  For example, when MTUI’s [Help] menu optionbutton is pressedselected,, the Web Browser with the Help information is displayed.

 

The Web Browser is already available in the offices for general access to factory information.  Since this uses the existing Web Browser technologies, we can eliminate the MS-Windows versus X windows platform issues: we have one technology for making the information available (via Web servers) and we buy the browsers as a commodity item for the computer platforms that we have.

 

The applications that use the Web Browser are not browser specific.  Web applications are as usable on Netscape as on Internet Explorer or any other first tier browser.

 

Results

 

We are still in the initial stages of deployment, so the final figures are not in yet.  Later this year we plan to conduct a new usage study to compare with the original usage study numbers for a full report.  However, we do have some preliminary numbers, and the signs are very encouraging.

Useability

 

Cycle Time. There is an estimated 26 second savings per lot processing operation by using MTUI rather than the older systems.  This may not seem like much, but when you multiply that across the 200-300 operations that each lot goes through, then multiply that by the number of lots in the factory, then by the number of factories, it adds up to an impressive savings.

Training.  In the initial implementation, instead of the traditional one or two day class, we used a short 1 hour familiarization session.  This is partly because the MT’s already knew the activities involved and only needed to know the new UI layout.  The MT’s commented on how easy it was to use and learn.

 

We have no data yet on the changes necessary for the full ‘new user’ training class.

Reliability

Again, it is still early in the implementation, so the data is sketchy.  However, the Java system so far has proven stable enough for production use.  We have had no significant issues there.

 

Because of the three-tier architecture design, we were able to add simple fail-over mechanisms in the case of server problems.  This has allowed MTUI to ride through some central server outages with no impact to WIP processing.

Supportability

The distributed nature of the UI clients presents problems in configuration and logfile management.  To some extent this is handled by using networked filesystems.

Problems

Problems are to be expected with new systems.  For MTUI, there are two main issues: readability and speed.

 

The readability issue is primarily from trying to pack a lot of text information into certain screens.  In order to get all the information the MT’s need, the font needs to be kept small.  This is acceptable on the large CRTs used on most stations, but is nearly unreadable on the poorer resolution flat-panel displays.  Adjustments of font and content will continue as the application matures.

 

The main drawback of using the Java system is speed.  The user interface should be snappy, reacting immediately to users’ requests.  As Java is still a new technology, the Java Virtual Machine leaves a bit to be desired in speed, especially in the rendering of windows.  We expect this to change as the JVM itself matures.  We are also working on ways to optimize the UI where possible.

 

A last issue is that not all the factory systems have been rolled into MTUI yet.  We have not yet achieved the goal of eradicating all the extra windows.  This is simply because of the large number of applications to work with: we started with the most important for WIP processing in order to get the job done for this generation.  In the next generation we will try to roll in the rest of the applications.

Future

There is always more to do.  In designing the initial versions of MTUI we sought to contain the scope so as to be able to be successful with a limited product.  In the next generation we want to add data graphing function for both real-time data capture as well as statistical process control data charts.  We are considering rolling the browser into a function card.  We are also looking at how to add more of the fab tool maintenance capabilities and shift-to-shift passdown communications.

 

The long term is unclear.  We have considered shrinking MTUI into a Java-based palmtop computer: linear space for CRTs in cleanroom is expensive, perhaps carry-around UI can help better utilize expensive fab-space.

 

Summary

 

User interfaces are tricky: in order to get all the functionality needed, compromises must be made.  We think that we’re on the right track with the choices we’ve made in our system.  It is flexible, easy to use, and provides protection from the underlying layers of the automation system.  We have a roadmap for enhancements, and a large user base from which to draw more ideas.

 

 

 

Figure 4. MTUI Screen