Download pdf - An intelligent agent framework for enterprise integration

lEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS, VOL. 21, NO. 6, NOVEMBEWDECEMBER 1991 1391

An Intelligent Agent Framework for Enterprise Integration

Jeff Y. C. Pan and

Abstract- A software technology for integrating people and computer systems in large, geographically dispersed manufacturing enterprises is described. The framework is based on the vision of a very large number (perhaps tens of thousands) of computerized assistants, known as Intelligent Agents, or U’s. Each IA supports a clearly discernible task or job function, automating what it can and calling on the services of other IA’s when necessary. IA’s can interact directly via a message bus, o r through a shared, distributed model (i.e., knowledge base) of the enterprise. Humans participate in this society of agents through personal assistants (or PA’s), a special type of IA that knows how to communicate both with humans, through multimedia interfaces, and with other L4’s and the shared knowledge base. Underlying the framework is the notion of an enterprise model that is built by dividing complex enterprise operations into a collection of elementary tasks or activities. Each such task is then modeled in cognitive terms and entrusted to an IA for execution. CASE tools supported by a library of activity models permit every individual in an enterprise to model the activities with which they are personally most familiar. The preliminary experimental results suggest that this divide and conquer strategy, leading to cognitive models that are buildable and maintainable by end-users, is a viable approach to real-world distributed AI. Moreover, it is believed that such a grass-roots, incremental modeling approach is the only practical way to integrate a complex enterprise.

I. INTRODUCTION

A. Motivation

NCREASINGLY, the productivity of complex, global en- I terprises is limited not by labor or capital, but information. Getting a product rapidly to market, for example, depends on countless, highly interdependent decisions by hundreds or thousands of individuals, senior executives to production workers, spread around the globe at corporate headquarters, engineering centers, factories, suppliers, and subcontractors. Decision making under these conditions is understandably slow, suboptimal and conflict prone. Such problems are only exacerbated by current computer systems that typically support individual departments (e.g., MIS, MRP, CAD, CAM), but rarely work effectively together. Similar observations can be made about managing virtually any large enterprise from a far- flung financial institution to a hospital, to the armed forces. An integrated enterprise computing environment must serve four fundamental needs:

Manuscript received December 7, 1990; revised April 2, 1991. This work was supported by the Defense Advanced Research Projects Agency under contracts N00014-87-K-0729 and N00014-90-5-4016.

The authors are with the Enterprise Integration Technologies Corporation, 459 Hamilton Ave., Suite 100, Palo Alto, CA 94301.

IEEE Log Number 9102920.

Jay M. Tenenbaum

Information Access-it should be easy to access the wealth of information resources and services available through corporate networks. Too often, those that need information do not know where to look or what commands to use. In general, data will have to be integrated from many sources to create customized information presentations for each individual.

Monitoring and Automation-even if one knows where and how to get information there is simply too much to keep track of. People and software need to be notified of decisions or events that affect them, so that they can take appropriate action.

Cooperative Work-people and computers need to work effectively as teams across time (e.g., through various stages of a product lifecycle) and space (e.g., design and production engineers working concurrently to resolve a problem). Team members need to share knowledge and information, and be alerted to potentially conflicting decisions.

System Integration-independently developed software packages must be easily integrated into the framework so that they interoperate seamlessly and are easily used and maintained. Additionally, the framework must provide an incremental path for migrating the enterprise from a purely “people-based’’ operation toward an environment in which people and computers work cooperatively. This evolution must occur without interrupting on-going operations.

B. A Vision of the IA Framework

In response to the above needs, we are creating a software framework for integrating people and computer systems in large, geographically dispersed manufacturing enterprises. It is based on the vision of human agents interacting with a large number of computerized assistants, known as intelligent agents, or IA’s. Each IA supports a clearly discernible task or job function, automating what it can and calling on the services of other IA’s, as well as human agents, when necessary. IA’s can interact directly via a dedicated message bus, or through shared data- and knowledge-bases. In our instantiation of this vision, illustrated in Fig. 1, these roles are played, respectively, by the IA Network and the MKS knowledge service [l], [2]. The core of MKS is a comprehensive object-oriented model of the enterprise and how it functions. The MKS model includes descriptions of personnel, facilities, equipment, inventory, manufacturing processes, and other corporate as- sets. It also captures the flow of information, decisions and materials through the enterprise-how things get done. The model is wired into the enterprise’s information infrastructure (databases, CIM systems, accounting systems, etc.) so that it continuously reflects the actual state of the enterprise. Agents

0018-9472/91$01.00 0 1991 IEEE

1392 IEEE TRANSACTIONS ON SYSTEMS. MAN. AND CYBERNETICS, VOL. 21, NO. 6. N0VEMBER;DECEMBER 1991

Fig. 1. An IA-based enterprise integration framework.

interact with these information resources through the model via high-level service protocols that insulate them from details such as where information resides. They can also register with the model their interest in particular events, and be notified when they occur. MKS thus serves agents as a repository for shared knowledge, and a center for information exchange.

IA’s model the perceptual, reasoning, action and communication skills involved in performing human job functions, such as those of an equipment operator, production scheduler, engineer, purchasing agent or manager. IA’s must therefore know what to look for, what to do when they see it, and who to tell, just like the person they model. Interactions among IA’s follow the established corporate lines of communication and procedures. Collectively, IA’s and their communication links form an active, operational model of an enterprise.

To participate in this society of agents, humans require the services of personal assistants (or PA’s). PA’s belong to a special class of IA’s that know how to communicate with humans through E-mail, graphical editors, and other standard modalities (e.g., beepers, faxes, telephone). They also know how to translate between these human modalities and IA network protocols. To facilitate the interaction, one’s PA maintains a personal model that includes where they currently are, how they can be reached, what information they would like monitored through the knowledge service, and what actions to take, either in response to messages from IA’s or notifications from the knowledge service. For example, reports of minor trouble might be forwarded auto- matically to a human subordinate or an IA, whereas a report of major trouble might warrant being paged. When a person responds to an IA message through their PA, that person is, in effect, acting as their own activity model. PA’s thus provide an element of completeness, enabling the modeling of activities that are too complex or too important to delegate to IA’s. Moreover, PA’s can help by anticipating and presenting supporting information from the knowledge service that will enable an individual to make informed decisions. Such an architecture supports the notion of man/machine cooperative work, as articulated by Winograd [3]. Indeed, it goes further in allowing tasks gradually to be handed off to IA’s so that ultimately they can be performed interchangeably by a person or their agent.

In addition to supporting traditional human activities, IA’s can also automate a variety of tasks for which people may be too expensive or otherwise limited (e.g., too slow, too

inattentive). Think of IA’s as an inexhaustible source of “cheap labor” that can provide dedicated human-like services, 24 hours a day, ubiquitously throughout the enterprise. IA’s can be dedicated, for example, to watch over each and every piece of equipment in factory and to shepherd each workpiece and piece of paperwork along their prescribed routes. Later, we give an example of such an Anthropomorphic IA (or AIA), a smart “agentized” wafer-lot that knows how to follow a recipe, negotiate with equipment IA’s to obtain needed services, and recover from breakdowns and processing errors. It is easy to envision a host of similar applications, such as equipment agents that bid for jobs in a job shop, and forms agents that know where to go for approvals. More sophisticated AIA’s can serve as dedicated liaisons between project teams to ensure that decisions are coordinated. They can provide enhanced information services, such as serving as a corporate services directory (“yellow pages”) or a broker that helps users and providers of services find each other. And they can encapsulate software packages, serving as intelligent front ends that actively solicit opportunities to provide service. Fig. 1 shows a variety of IA’s, MA’s, and PA’s representing people, equipment, software, databases, and workpieces.

For the framework to succeed in an operational setting, we believe it is essential that the enterprise models underlying IA’s, PA’s and MKS be created and maintained by the people they serve-the end-users that understand best the tasks to be modeled. Two features of our approach help make this possible. First, partitioning complex activities into simple tasks and modeling them in cognitive terms produces models that are familiar to workers, and therefore easy for them to understand. Second, we are developing simple modeling tools for end- users, that enable them to copy and customize generic activity models (e.g., for monitoring, transactions, brokering) from a library. Customization might require editing a script or fleshing out a decision tree, but such skills can be quickly mastered when the editing tools support representations that are already familiar [4], [5].

Initially, an enterprise framework would consist mainly of simple PA’s that support current people-based styles of work. The initial PA’s would be little more than editors that knew how particular individuals liked their information presented from the MKS knowledge service. Individuals using the above tools, would gradually hand off more and more of their routine responsibilities to IA’s and their PA. IA’s would be programmed to filter out uninteresting information and respond to routine events in standard ways. For example, an equipment operator might task an IA to watch the MKS model for particular equipment breakdowns, and then take appropriate actions, such as alerting maintenance personnel (or their agents), or running a program to reschedule production. Over time, the number and responsibilities of agents would grow. Ultimately, the enterprise might have thousands of IA’s overseeing virtually every activity, ensuring that information flows swiftly and that nothing slips through cracks. The vision that emerges is a flood of information coursing over the enterprise. Fortunately, everyone has their PA’s and IA’s to protect them from drowning by dispatching routine matters autonomously.

PAN AND TENENBAUM: AN INTELLIGENT AGENT FRAMEWORK FOR ENTERPRISE INTEGRATION 1393

In the remainder of this paper, we flesh out this vision and describe a prototype implementation, currently under development, that will run the semiconductor fabrication facility at Stanford’s Center for integrated Systems (CIS). Section I1 is a review and rational reconstruction of previous work, retracing the development of ideas leading to the IA framework. Sec- tions IIi and IV provide technical details on the framework and its implementation. Section V reports on preliminary experiments with the prototype at CIS. Finally, Section VI summarizes our results to date and draws implications for both distributed AI and enterprise integration.

11. BACKGROUND

The IA framework evolved from three key ideas that emerged from our research on AI in real-world manufacturing environments: end-user programming, divide and conquer (modularity), and shared knowledge bases. We shall now bridly retrace this evolution.

A. End-User Programming

Since 1984, we have been studying applications of expert systems in manufacturing. An early insight was that the complex and dynamic nature of manufacturing knowledge made it highly desirable for manufacturing personnel to do their own knowledge engineering. To make this possible, we performed multilevel knowledge engineering, developing knowledge representations that were natural for our end-users rather than elegant in an AI sense. We also created editing tools with which such users could, themselves, flesh out and maintain the representations. The tools were easy to learn and use because they presented information in familiar graphical formats such as flow charts and decision trees.

PIES [4], the first of these applications, was a system for interpreting parametric test data in semiconductor manufacturing. Without getting into detail, the system allowed test engineers to create a graphical dependency network show- ing possible processing problems, each linked to causes and symptoms. On-line tester data could be interpreted automat- ically using this knowledge base, so that when a processing problem occurred, a rank-ordered set of potential problems and causes was generated. If the system failed to interpret the test data correctly, it was straightforward for an engineer to edit the diagram, adding new problems, symptoms or causes as appropriate. Over time, the dependency network grew to encompass a significant fraction of the test engineer’s experiential knowledge. Whereas the engineer previously had to spend almost half his day analyzing the torrents of data produced for each wafer lot just to verify that the overall process was healthy, he could now turn most of this onerous task over to HyperPIES [5] . We had thus built our first user- programmable IA, although we had not yet conceptualized it in this way.

B. Modularity

The association of symptoms, problems and causes underlying PIES was both a simple and generic approach to monitoring. One can envisage many applications .for such a

system throughout a factory, and indeed a half dozen others were developed using essentially the same representation and editing tool. We also experimented with a simple user- programmable expert system shell for monitoring and control applications. It was observed that for most factory equipment, there were relatively few things that could be monitored and controlled. Moreover the relationship between what was monitored and what control action(s) to take could often be expressed in the form of simple analytic relationships and/or a few production rules: if data value A is too high, reduce control knob B, and so forth. This suggested a divide and conquer strategy for automating complex manufacturing processes. Instead of developing massive 100 000 rule expert systems for running an entire factory, it was much easier to create many simple 5-10 rule systems, each of which monitors and controls a single process step, or even step parameter. Such modular systems were again simple enough that the operators of each piece of equipment could program their own agents to respond just as they would. It is a simple extension to allow these agents to send messages to each other, to implement elementary forms of feedback and feedfonvard control (e.g., “this wafer was left in the furnace too long, so etch it longer at your station). These were early forms of IA protocols.

C. Shared Knowledge Base

It quickly became apparent that a factory automation system constructed in this way could consist literally of hundreds or thousands of such simple expert systems for monitoring, con- trolling, diagnosing or scheduling processes and equipment. Each of these systems requires models of selected aspects of the manufacturing environment as well as knowledge about a particular manufacturing task. It appeared impractical to hand- craft so many individual models and knowledge-bases from scratch and keep them up-to-date and consistent. Moreover, when each application module maintains its own knowledge- base, the resulting fragmentation of knowledge can adversely affect decision making. For example, when information about equipment maintenance schedules and diagnostic procedures resides in different modules, it may be difficult for the diag- nostician to connect an observed degradation in yield with a recently performed maintenance procedure. As in other software domains, sharing and reuse of knowledge, models, and problem solving methods are essential.

This motivation led directly to MKS [l], a prototype framework for sharing and coordinating information in a manufacturing environment. MKS was based on the premise that many software applications in a given manufacturing environment have broadly overlapping knowledge requirements. In a semiconductor fabrication facility, for example, process simulation, diagnosis and scheduling all require knowledge of the process recipe and equipment. This knowledge can be represented once and shared by all applications that need it. Similarly, all instances of a generic class of equipment (e.g., furnaces, implanters, etchers) have a great deal of knowledge in common-what they do, how they work, how they fail and how they can be diagnosed. Capturing this common knowledge once and for all in a shared model reduces the

1394 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS, VOL. 21, NO. 6, NOVEMBERIDECEMBER 1991

UIPMENT ENGINEER FACILITIES ENGINEER

PROCESS; PRODUCT;

EQUIPMENT; FACILITY;

OPERATIONS, etc PLANT MANAGER / I \

/ I \ (Supporting Applications)

MONlTORlNGlCONTROL

Fig. 2. The MKS model-centered architecture.

development cost and size of the application modules that use it, and greatly simplifies maintenance. It also facilitates inter- module communication by providing a natural structure where information can be left for modules that need it.

On this view, the MKS architecture consists of application modules (the precursor of agents) that interact with each other and with CIM resources (databases, on-line equipment) through a shared object-oriented model of the manufacturing environment (see Fig. 2). The MKS model contains objects corresponding to all significant entities in a manufacturing environment: processes, equipment, facilities, raw materials, personnel, and so forth. Surrounding the model are graphical editors that allow manufacturing personnel to create, inspect and modify the shared model using familiar metaphors such as process flow charts and equipment block diagrams. Also shown are three representative application modules (diagnosis, monitoring, scheduling) that use the model to plan and run

production. More recently, the MKS model has evolved into a dis-

tributed knowledge service that is accessed by applications using standard service protocols [2]. This service is the foundation of the enterprise integration framework depicted in Fig. 1. The editors shown in Fig. 2 can now be seen as early versions of PA’s, and the applications as early versions of IA’s. Indeed, the dependency graph labeled Diagnosis in the lower left corner of the figure is the editing tool for HyperPIES, mentioned above as a precursor of IA’s.

The research described in this paper extends the MKS model beyond the factory floor to encompass other essential manufacturing and enterprise activities, such as marketing, finance, and engineering. More fundamentally, IA’s add a new dimension to the MKS model, capturing activities such as monitoring, reasoning, decision making and communicating, that have heretofore been the province of human “agents”.


With IA’s, MKS is ready to move beyond its original role as a passive repository of knowledge and become a full-fledged active partner, sharing responsibility with people in running an enterprise.

D. Relation to Other DAI Research

We recounted the historical development of IA’s at some length to underscore that our approach to agent research evolved independently from traditional distributed AI approaches [6]-[ 111. Nonetheless, there are clear similarities in both motivation and philosophy with DAI, particularly with the work of Hewitt and his associates on Actors, Orgs and Tcams. Both IA’s and Actor/Orgs. for example, are predicated on local, modular models of computation that deal with complexity the same way real-world organizations do: by delegating responsibilities for tasks to individual agents and leaving the details of coordination up to them. Extending the analogy, the shared archive in Kornfield and Hewitt’s scientific community metaphor [12] plays a role similar to the MKS model, both facilitating agent interactions. The differences between IA’s and other DAI paradigms are largely ones of cmphasis. The emphasis in our work is squarely on finding pragmatic approaches to cooperative, distributed problem solving (CDPS) [8] that work in real-world organizations. Thus, instead of attempting to develop sophisticated knowledge agents with goals, plans and beliefs, we are concerned with developing the tools and distributed infrastructure that will enable end-users to program simple agents that do useful things for them. Instead of formalizing goals and beliefs in logic, we perform metaknowledge engineering on organizations to understand the generic roles (e.g., broker, monitor, expediter), tasks, activities and communication protocols that must be represented to facilitate cognitive modeling. Moreover, the representations are chosen on pragmatic grounds-finite state transition graphs, production rules, decision trees and so forth-whatever our users find most natural for expressing what they do. Contrast this, for instance, with Hewitt’s formal characterizations of agent behavior in terms of programming semantics. Our pragmatism should not be construed as being anti-theoretical. On the contrary, the IA framework provides an ideal real-world environment for experimenting with sophisticated agents and formal approaches’. Indeed, IA’s can be regarded as one of the first attempts to apply Hewitt’s conceptual framework to real organizations.

A final distinction is that we are fundamentally committed to a cooperative man-machine approach to enterprise integration. We believe that completely automated factories are neither possible nor desirable in the foreseeable future. We are therefore concerned with how human and computerized agents can interact symbiotically, and how automation can be achieved in an orderly, incremental way. In this sense, our work also owes an intellectual debt to concepts from collaboration theory and computer-supported cooperative work (CSCW) [3], [13]-[16]. However, most CSCW research to date has not explicitly concerned itself with sharing decision

’ It does appear, however, that a surprising number of real-world activities can be decomposed and modeled using simple agents.

making responsibilities between humans and computer agents. In order to feel comfortable and make informed decisions, humans must be able to understand the reasoning processes of their computerized counterparts. This understanding is facilitated by our insistence that IA’s faithfully model the reasoning and interagent communication processes found in human-run organizations.

The pragmatic approach taken in our IA research provides some useful insights on DAI, which are addressed as part of the discussion of future work at the end of this paper.

111. THE IA FRAMEWORK

A. Technical Overview

The IA framework, illustrated in Fig. 3, consists of three synergistic technologies: intelligent agents, the MKS knowledge service, and a distributed system infrastructure (not shown). IA’s interact with humans through their Personal As- sistants (PA’s) over an enterprise-wide network using standard service protocols. IA’s can also access information resources, control on-line equipment, and trigger other IA’s indirectly through the MKS knowledge service [2].

Each computerized agent is an active, autonomous process that models a single discernible task. The task may be either one traditionally performed by a human or one suitable for an anthropomorphic IA (e.g., a “smart” wafer). Activities are described by corresponding “activity” objects in the MKS model, in terms of the information they consume, process and produce, and the other MKS model objects (people, equipment, wafer lots and so forth) that participate. From such descriptions, IA’s can determine what information and events to monitor and how to respond (e.g., what to see, what to do, and who to tell). For example, the behavior of the IA tasked with monitoring the Tylan furnace (top of Fig. 3) is defined by the CIS-Tylan-Monitoring activity object in the MKS model (bottom of Fig. 3). More specifically, the MKS equipment object “CIS-Tylan-furnace: is designated as the equipment to monitor, and the MKS job-position (personnel) object “CIS-furnace-operator’’ is assigned as the equipment operator.

An IA framework for an enterprise is built in two stages. First, enterprise activities are modeled in cognitive terms and added to the MKS model as Activity Objects. Second, these activity models are selectively activated as IA’s, to actually perform the modeled tasks. We shall now cover each of these steps in some detail.

B. Activity Modeling

We will now present a generic approach to activity modeling and illustrate it with examples drawn from semiconductor fabrication and other manufacturing domains. This representation of activities augments the existing representations of manufacturing processes, facilities, equipment, personnel and work in progress in the original MKS model to define the behavior of IA’s.

We model activities in cognitive terms that make the models easy for our users to understand and maintain. Ask an indi-


n

Fig. 3. IA framework and supporting MKS model library.

vidual to tell you about their job and they will likely describe it in terms such as what situations and events they look for in the environment, what actions they take in response, who they report to, where they turn to for help when something goes

wrong, and so forth. Probe deeper and you will get details such as that the boss wants certain problems reported via E-mail and others via printed memos, or that in the event of engineering changes, one should consult the corporate procedures manual

PAN AND TENENBAUM: AN INTELLIGENT AGENT FRAMEWORK FOR ENTERPRISE INTEGRATION

__

1397

and current organization chart to determine who needs to sign off and in what order. Ideally, one should be able to create activity models that closely resemble such descriptions, right down to the references to organization charts, procedures manuals, catalogs, and process or information flow models, all of which can be represented in MKS.

Following the object-oriented methodology of MKS, individual activities are modeled by customizing generic activity models from the MKS library. The MKS library of activity objects is organized as a classification hierarchy according to the nature of the work performed. Fig. 3, for example, illuslrates a simplified task taxonomy for semiconductor fabrication.

Each activity object contains the knowledge necessary for performing a specific job (i.e., the modeled activity). The knowledge is provided in the form of a template that defines the essential elements necessary to construct a cognitive model for performing the task: the players, capabilities, states, and sensory inputs, and the core model consisting of sets of message and sensory input-patterns, action sets, and the pattern+acfion rules (i.e,, reasoning) that associate them, as shown in the bottom of Fig. 4.

Each of these categories have an intuitive semantics. I ) Players are the operands involved in an activity, and

are specified generically where possible (e.g., a job role versus a specific person).

2) Capabilities are an optional description of the tasks an agent is capable of performing, with applicable charges to use when bidding for jobs.

3) States are the natural contexts that people use in deciding what to look for and what actions are appropriate. (Perceptions and actions can also be conditioned on goals, resources and other cognitive concepts, where appropriate.)

4) Sensory inputs specify the sources of data to monitor and the specific patterns to look for (as functions of state).

5 ) Core Model defines the IA’s behavior in terms of sensory, action, and reasoning patterns:

a) Sensory patterns define what to look for. They can be as simple as a pair of range limits for a measurement gauge, or as complex as a sequence of MKS model states, indicative of an incipient quality problem on the shop floor. Message patterns are the IA messages that are meaningful in the context of a particular activity, such as the commands Shut-Down and Process, which are meaningful to an equipment operator. Action sets are detailed sequences of actions exe- cuted to accomplish some result, such as shutting down a piece of equipment. An Action Set can range from the detailed sequence of control knob settings involved in a shut down, to such simple acts as issuing an IA command or changing a model’s internal state. PatternjAction rules specify what actions to take in response to sensory input patterns and IA messages, as a function of state.

b)

c)

d)

While Pattern + Action rules are the only form of reasoning shown in Fig. 4, and the major representation used in our experiments to date, other intuitive behaviorial representations have been used where they contribute to ease of expression and comprehension. Examples include state transition diagrams, petri nets, flow charts, decision trees, and scripts. The choice depends on what is most natural for the task at hand. Oc- casionally, complex behaviors require escaping to program code (which for end-users involves securing the services of a programmer).

Let us now consider a specific example of an activity model governing equipment operation. A generic equipment monitoring object will describe how an equipment operator does his job: what equipment “failures” can be expected, how can they be recognized, and what site-specific procedures should be invoked in response to the detection of such failures. Fig. 5 shows an instantiation of such a model, describing how the CIS Tylan furnace should be monitored. The Players section specifies the “operands” involved in this activity: the OPERATOR slot specifies the person on duty (i.e., CIS-Tylan- furnace-operator) who has the responsibility of monitoring this furnace; the EQUIPMENT slot designates the particular furnace to be monitored (i.e., CIS-Tylan-Furance); and the WAFER-LOT slot identifies the lot being loaded and processed at this time. The next two sections define local Constants and State Variables relevant to this IA (e.g., the maximum time to wait for a call-for-service before an alarm is triggered; the current state of furnace operation; and the computational process that executes this active IA), and the 6 possible Operating States that this equipment can be in at any particular time (based on a state-transition model of furnace operation): NORMAL-RUN, LOADING, UNLOADING, IDLING, EMERGENCY-SHUTDOWN, and BROKEN. The Sensory Inputs section describes: the data sources that need to be watched in each states; how the data is to be acquired; and what minimal acceptable sampling rate should be imposed. Finally, the Core Reasoning section catalogs the symptoms to watch for and the desirable actions to take in response. In this example, if the temperature difference exceeds 10 degrees in the NORMAL-RUN state (about two thirds down in Fig. 5), then commands are issued to shut off the equipment and inform the equipment operator. Note the generic reference to this OPERATOR, rather than to a specific person who might not be on duty. We shall return again to this example in later sections.

Fig. 6 illustrates an activity model for a simple AIA, a wafer-lot “genie” that knows how to look after a lot as it wends its way through the fabrication process. The representation is completely analogous to that of an ordinary IA.

C. Building Generic Activity Model Libraries

Following object-oriented design practice, models of specific activities, such as those given above, can be generalized to create reusable libraries of objects that model generic job roles. Thus, the Tylan-furnace-monitoring object can be stripped of specific references to Tylan’s and reused directly as a template for monitoring furnaces from other manufacturers. More


AGUOVOUV QBQEGU P L A Y E R S / o p e r a n d s :

C A P A B I L I T Y :

S T A T E S : ( i d l i n g ho ld ing- in -queue being-processed t r a s h e d )

CURRENT-STATE: be ing-processed

S E N S O R Y - I N P U T S :

CORE-MODEL:

' Sensory Pattems Message Patterns Action Sets

* Pattern=>Actbn Rules

Fig. 4. An activated IA and its activity object.

interestingly, removing the specific references to monitoring temperature differentials leaves an activity template (e.g., defi- nitions of players, specific states, sensory inputs, pattern-action rules) that can be reused for monitoring many other types of semiconductor equipment. In essence, the role of an equipment monitor is to watch for events, that may depend on processing state, and take actions that may include adjusting or shutting down a machine, or notifying maintenance and operations personnel. Similarly, the wafer agent can be generalized to serve as a role model for any agent that guides a workpiece

through a manufacturing process, following a recipe. It must know where to go next, what to do if a test is passed or failed, how to negotiate for services and so forth.

We have begun building a comprehensive library of generic activity models for semiconductor manufacturing, together with libraries of generic methods for sensing, reasoning, communicating, and taking action. We are also developing activity modeling tools analogous to the MKS modeling tools for processes, equipment and the like. They will make it possible to select an activity object from a library that has


..__________________------------------------------------------------------------ I I

Wafer-Lot-monitoring (a-k-o anthropomorphized-activity-object) ;; Players WAFER-LOT[WIP]: B231.A ;; Local Constants and State Variables PROCESS-RECIPE[process-step]: CIS-BiCMOS-process CURRENT-PROCESS-STEP[process-step]: FIELD-OXIDATION-M2 EQUIPMENT-ASSIGNED[equipment]: CIS-Tylan-Furnace CURRENT-STATE: BEING-PROCESSED CORRESPONDING-IA-PROCESS: #< IA PID 23546> ;;it’s activated! ;; Sensory Inputs EQUIPMENT-STATUS: ACTIVE-WHEN: (WAITING-IN-QUEUE BEING-PROCESSED DATA-SOURCE: (ask-MKS-model (this EQUIPMENT-ASSIGNED) ‘STATUS) SAMPLING-RATE: 5 min

;; LOT states STARTING[state]: WAITING-IN-QUEUE[state]: BEING-PROCESSED[state]: IDLING[state]: COMPLETE[state]: RUINED[state]: ;; Core Reasoning Model: ABORTED-WHILE-PROCESSING: PATTERN: (and (at-state ’BEING-PROCESSED) ( = EQUIPMENT-STATUS ‘DOWN)) ACTIONS :

;; Equipment down while lot is being processed-may have to be

(message-IA ‘inform (the PRODUCT-ENGINEER) “Abort while

(change-my-state ‘RUINED) ABORTED-WHILE-WAITING:

scraped

processing” )

PATTERN: (and (at-state ’WAITING-IN-QUEUE) ( = EQUIPMENT-STATUS ‘DOWN)) ACTIONS :

;; Equipment down while lot is waiting in queue (message-IA ‘inform (the PRODUCT-ENGINEER) “Attempt to re-assign

(message-IA ‘request *MYSELF* ’EXECUTE-PROCESS-STEP) (change-my-state ‘IDLING)

equipment” )

ASSIGN-EQUIPMENT[message]: ACTIONS :

(ask-MKS-model (this CURRENT-PROCESS-STEP) ‘EQUIPMENT-ASSIGNED ’TO-ASSIGN) EXECUTE-PROCESS-STEP[message]: ACTIONS :

(message-IA ‘request (message-IA ‘inquiry *MYSELF* ‘ASSIGN-EQUIPMENT)

‘ENQUEUE-LOT (this WAFER-LOT) :when-completed (message-IA ‘request *MYSELF* ‘PUSH-NEXT-PROCESS-STEP) )

(change-my-state ’WAITING-IN-QUEUE) ..__----_----------------------------------------------------------------------- I f

Fig. 5. Activity object modeling a wafer lot “genie.”

been predefined for common high-level tasks (e.g., equipment control) and customize it by selecting and composing desired sensing, data processing, decision making, and action behaviors from other libraries containing primitive behaviors. For example, to customize an operator’s activity model for a new piece of equipment, one would specify an appropriate sensory interface to receive data; processing to validate the data; a rule-based decision procedure for monitoring, control and diagnosis; and the players to be notified when equipment problems are suspected. Libraries and CASE tools effectively raise the level of vocabulary used for modeling.

While our experiments, thus far, have focused on semiconductor manufacturing, our cognitive approach to activity

modeling clearly extends to work roles in general. Look at what people do in any manufacturing enterprise and you will see instances of the same generic job functions: managers, brokers, expediters, “paper-pushers,” and their specializations, such as sales manager and shipping broker. In building a library of such activity models, one would again abstract the behaviors and communication protocols common to each job type. Brokers, for example, match buyers and sellers of goods or services, and receive commissions. This generic description applies whether the commodity being brokered is a financial service such as securities, real estate, or insurance, a transportation service, or tangible goods. At the behavioral level, brokers solicit bids, select the best price, and award

1400 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS, VOL. 21, NO. 6, NOVEMBEIUDECEMBER 1991

..__________________------------------------------------------------------------ I 1

CIS-Tylan-furnace-monitoring (a-k-o activity-object) ;; Players OPERATOR[job-position]: CIS-Tylan-furnace-operator ;; Mary is the operator on duty EQUIPMENT[equipment]: CIS-Tylan-Furnace WAFER-LOT[WIP]: B231.A ;; a 5-inch lot of 23 wafers running the BiCMOS process ;; Local Constants and State Variables MAX-REPAIR-CALL-WAIT: 30 minutes CORRESPONDING-IA-PROCESS: #< IA PID 23546> ;;it's activated! CURRENT-STATE: NORMAL-RUN ;; Tylan Furnace Operating States NORMAL-RUN[state]: LOADING[state]: UNLOADING[state]: IDLING[state]:

;; Sensory Inputs TEMP-L[temperature]: EMERGENCY-SHUTDOWN[state]: BROKEN[state]:

ACTIVE-WHEN: (NORMAL-RUN IDLING) DATA-SOURCE: (ask-MKS-model (this EQUIPMENT) 'TEMP-L)) SAMPLING-RATE: 2 min

TEMP-S[temperature]: ACTIVE-WHEN: (NORMAL-RUN IDLING) DATA-SOURCE: (ask-MKS-model (this EQUIPMENT) 'TEMP-S)) SAMPLING-RATE: 2 min ; .... ;; Core Reasoning Model PATTERN :

TUBE-LEAKAGE:

( > (difference TEMP-S TEMP-L) 10) ;;alert if more than 10 degrees of diff.

ACTIONS : (message-IA 'request (this OPERATOR) 'EMERGENCY-SHUTDOWN

:people-message "Tube Leakage Detected" :max-wait 120 :if-timed-out

(message-IA 'inform (the FACILITY-MANAGER) (message-IA 'request (the FACILITY-MANAGER) 'GENERAL-ALARM) )

"Tube Leakage Detected; Equipment shutdown attempted" ) ;;an open-bid is broadcasted within CIS, calling for response from

(message-IA 'bid ;; targeting message by role and capability maintanence

(CAPABLE-OF '(:task 'EQUIPMENT-REPAIR :subject (this EQUIPMENT :description 'TUBE-LEAKAGE) :role 'MAINTENANCE ) :max-response-time (this MAX-REPAIR-CALL-WAIT) :broadcasting-scope 'CIS-only :if-no-response (message-IA 'inform (the FACILITY-MANAGER) ;; call by "role" "No maintenance response on time for down equipment" ) )

(change-my-state 'EMERGENCY-SHUTDOWN) ..__________________------------------------------------------------------------- I I

Fig. 6. Activity object modeling the tylan furnace monitoring task.

contracts. They communicate with clients using terms such as bid and asked, with associated constraints on cost and time. A more detailed scenario of enterprise-level job modeling, and the associated modeling tools to support it appears in Section V.

D. Intelligent Agents

Technically, an IA is a computational process that derives its behavior from an MKS activity object, and communicates with other IA's following a well-defined protocol. However, the essence of being an IA is being alive-responding au-

tonomously and proactively to perceptions. An IA playing the role of an equipment operator, for example, can sample equipment data periodically, determine whether the equipment is operating properly, and if not attempt to take corrective actions, ranging from adjusting "control knobs" to instituting an emergency shut down. Other agents may need to be informed about an action, such as notifying maintenance and scheduling IA's about a shutdown. In the following subsections, we first discuss the agentification process by which a passive activity object, like that shown in the bottom of Fig. 4, is transformed into the living IA depicted in the top


of Fig. 4. We then elaborate on the process by which IA’s communicate with each other.

E. Agentification of IA ’s

Agentification refers to the three steps involved in creating a computational process(es) (i.e., an IA) whose behavior mimics that described in a corresponding activity object. First, a unique instance of an activity object is created from the MKS library-a surrogate for a particular agent performing a particular task. Second, one or more computational processes are created to implement the “autonomous” agent’s sensors and behavior. Finally, these processes are activated so that they can begin receiving and responding to sensory data and incoming IA messages. We will now elaborate on each of these steps.

F. Instantiation

Instantiation involves customizing the object template copied from the MKS activities library for the specific task at hand. In the example shown in Fig. 5, the CIS-Tylan- furnace-monitoring object is an instantiation of a generic Tylan-furnace-monitoring activity object in the library (details not shown here), with context-specific information about the exact facility and operational context: which furnace is involved; who is the operator on duty; which wafer-lot, if any, is being processed, and so forth. In the extreme, customization may require communication channels that extend beyond the scope of the IA network (e.g., commands to turn off a piece of physical equipment, or to send E-mail to a person without a PA.)

G. Process Creation

Having instantiated an activity object for a given job, the next step is to create processes that efficiently implement the proscribed behavior in a given runtime environment. Think of these processes as interpreters that translate the concise behavioral descriptions provided by activity objects into the best possible runtime implementations. For example, suppose that an activity model calls for periodically monitoring a data source. Under MKS, such a requirement can be translated into a simple registration of interest with the notification mechanism [1]. The process can then remain suspended, consuming no CPU cycles, until a change to the subject data is reported to the MKS model. If such a mechanism is not available, a process would be created to periodically sample the data source in response to clock interrupts. The intent, in either case, is to insulate the model builder from implementation details.

To maximize flexibility, separate processes are established for an IA’s reasoning engine and each of its primary sensory and communication inputs. Each such receptor process is then “trigger-wired’’ to its corresponding data source in the most computationally parsimonious fashion. The LA network is now ready for activation.

H. Activation

The final step is actually to arm the sensor processes so that they “watch” their assigned data sources. Simultaneously, all

the IA-message listeners and transmitters are switched on so that IA’s can exchange requests and inquiries through the IA network. The process implementing the reasoning engine is placed in a continual stimulus-response mode. When a “stimulus’’ arrives, either as a symptom detected by one of the IA’s sensory sub-processes, or through a message received from another IA, the reasoning process is invoked to generate the proper responses and actions, following the decision procedure (e.g., production-rule, state transition diagram, decision tree) contained in the activity model, as in Fig. 4.

I. The LA Network

The IA Network is a logical communication bus, designed exclusively for exchanging messages among IA’s in a special format, known as the IA protocol. An IA message, based on the IA protocol, allows an IA to report to or request services from other IA’s. Even though IA messages may be broadcast over the same physical network as other logical communication protocols (e.g., the MKS protocol, over an Ethernet), their high-level semantics provide concise, natural, and comprehensive communication among IA’s. Describing communications among IA’s in this high-level vocabulary also insulates an enterprise’s activity model from the implementation details of its network infrastructure.

J . Composition of an IA message

An IA-message consists of four parts: 1) the message type, specifying the kind of communication pattern to be engaged in; 2) a “target” description, addressing the intended IA(s) either directly by name(s), or indirectly by role, interest, or capability/qualification; 3) the “body” of the message which is to be sent to the targeted IA(s) and interpreted within its context; and 4) an optional list of keyword arguments detailing interactions (e.g., what to do should a message fail to find its targeted IA within a specific time limit).

K. Message Style

An IA message can be either open or closed. IA messages that inform and request are typical of open messages: their primary purpose is one-way communication, with the possibility of some exception handling (e.g., if the message is rejected or timed out). Inquiries, on the other hand, are typical of a closed message: the sending IA usually requires the information requested from the targeted IA to accomplish some task.

L. Message Type The message type tells the targeted IA what kind of interac-

tion is to be conducted. Each message type is associated with a set of default constants (e.g., how long to wait before declaring a time out), and actions (e.g., what to do if a time out occurs). Individual defaults can be selectively modified or overwritten with optional keyword arguments. Some keyword options are generally applicable to all types of IA messages (e.g., :if- timed-out, :if-rejected, :broadcasting-scope), while others are applicable only to a particular type of message, as illustrated below. There are four types of IA messages that are currently

1402 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS, VOL. 21, NO. 6, NOVEMBEIUDECEMBER 1991

adopted for our IA system: INFORM, REQUEST, INQUIRY, and BID. We will now briefly describe the semantics of each message type, together with their applicable keywords.

INFORM: An open message, intended primarily for passing textual information to an IA(s), for forwarding to the most appropriate person. The receiving IA gets to decide who is the most appropriate person in its own context (e.g., Mary, the operator on duty). It can then forward the message to that person's PA, which may decide, for example, to send himlher an E-mail with the message as its contents. The syntax of this message also permits an optional :action keyword, for sending a request message to the targeted IA. < message-body>::=

(< text-message intended for "people"

[:action < accompanied action requested

REQUEST: A complement of the INFORM-type message, whose primary purpose is to request actions or issue commands to the targeted IA. Its syntax allows an optional < message-body>::=

behind the targeted IA>

of the target IA>] )

( < action requested to the target IA> [ :people-message < "CC" for "people" associated with the IA>] )

INQUIRY: A closed message designed to acquire information through another IA. On sending a closed message, an IA will be suspended until the expected information becomes available. A special feature for this type of message is that default behaviors for an aborted situation (e.g., :if-timed-out or :if-rejected) will terminate the suspension-a precaution to prevent permanent "hanging" of the IA due to an inquiry that cannot be satisfied. (While awaiting the results of an inquiry, the process will continue to respond to sensor inputs and IA messages).

BID: A composite message encompassing three stages of behavior: 1) broadcasting messages to a set of targeted IA's inviting them to submit bids to supply service, with associated costs; 2) evaluating all bids received within the :max-response- time and selecting the "winning" bid according to the :cost- function; 3) sending out a request message with the winning bidder as the targeted IA.

In addition to the keywords discussed above within the context of particular message types, here is a list of keywords generally applicable to all IA-messages. They allow customization of an IA's basic (i.e.,, default) behavior in handling messages. : max-wait

< max waiting time before enacting :if-timed-out method> ;; default-30 s.

:if-timed-out < action to take if timed out while waiting for response from target IA> ;; default-E-mail report to the human host of the IA.

:if-rejected < actions to take if rejected by the targeted IA>

;; default-E-mail report to the human host of the IA.

:broadcast-scope <range of the IA network over which a message will be propagated>

;; default-the IA network bounded by local network gateways.

The IA message format allows targeted IA(s) to be described by their names, by their roles (including their interests), or by their capabilities. Calls by role requires that the targeted IA be determined dynamically in the context of current IA, including the use of an enterprise organization chart (e.g., "the FACILITY-MANAGER' refers to the person who now occupies the job-position FACILITY-MANAGER at the facility implied by the current context of the IA from which the message is issued-see also of the syntax defined for the the option for target description below). Call by capability, on the other hand, requires that a generalized pattern (i.e., the qualification spec.) be broadcasted and interpreted by all IA's within the specified broadcast scope.

< targeted IA(s) description> ::= < individual-IA> I (LIST-OF < individual-IA> [ . . . I ) I f .. --- CALL BY CAPABILITY

I (CAPABLE-OF < Qualification Spec> ;;< Qualification Spec> to be evaluated

by each potential targeted IA

everyone by default if not specified [:ROLE < ROLE-name>] ) ;; target on

< individual-IA> ::= < IA-name> ;; name ofthe targeted IAhas

been directly given (i.e, hardwired)

I (THIS<ROLE-name>) ;;targetedIAcan ;; --- CALLBYROLE

be deduced from IA's local info ; ;e.g. In Fig. 5 'I (this OPERATOR) " referstowhat is locallydesignated

I f .. in the OPERATOR attribute (i.e.f the " CIS-Tylan-f urnace-operator'' )

I (THE<ROLE-name>) ;;targeted IAcan bededuced fromIA's dynamic context

;; e.g., InFig. 5, "(theFACILITY-

I f .. MANAGER)" referstowhoever happens

to holdthe job-positionof CIS facility-manager at the time.

M. Personal Assistants

As discussed earlier, Personal Assistants are a special class of IA distinguished by their ability to communicate with peo-


(Enterprise IA Network)

(<- to other In’s) (to other IAs ->)

Fig. 7. Jeff encapsulated in his PA.

ple as well as with other IA’s. They encapsulate individuals, enabling them to interact with other IA’s using the network protocols and to act as their own (i.e., living) activity model, as caricatured in Fig. 7.

Each PA maintains a personal activity model of the individual it serves. Your PA model would include the following information about you: - where you are - how to contact and communicate with you (e.g., E-mail,

fax, phone, X-terminal, pager) - your capabilities (a list of tasks you are qualified to

perform)-your responsibilities (a list of tasks currently assigned to you)

- IA’s supporting your current tasks. - your general and task-specific information needs and

- your preferences for how information should be pre-

- activity models for personal tasks. Using this information, your PA can perform a variety of

services on your behalf. For example, it can monitor incoming information for you 24 hours a day (e.g., read your E-mail buffer, messages from your IA’s, or notifications from the MKS knowledge service). Routine events can be handled autonomously, such as by dispatching them to a human subordinate or an IA, while important issues and information are brought to your attention.

Like any IA, PA’s, in principle, can be programmed to perform any task. The key to making PA’s useful in an enterprise setting are the modeling tools and libraries of PA templates that make it possible for users to customize their own PA’s. It should be trivial, for instance, for a person to tell their PA how often to monitor their mail and under what circumstances they want to be notified at home. The prototype modeling tools we are developing for this purpose resemble similar tools in MKS [ 5 ] .

interests

sented

IV. IMPLEMENTATION

Our experiments with IA’s are being conducted at CIS, which provides a rich, yet accessible real-world manufacturing environment. The IA architecture is being implemented as an extension to the MKS framework [l] , by adding a sub- hierarchy to the MKS model taxonomy that includes the

activity library and instantiated activity objects. IA’s also use the MKS knowledge service [ 2 ] to access real-time, manufacturing data from the CIS fabrication line.

Like MKS, the IA architecture is being prototyped in the Hyperclass object-oriented programming environment [HC], implemented on Lucid CommonLisp version 3.0. A distinctive feature of Hyperclass is MetaClass, a toolkit for rapidly constructing customized interactive graphical editors. Meta- Class is being used extensively to create specialized editors for building of IA activity models. Additionally, it helps us prototype the graphical user interfaces by which PA’s interact with their human masters. The multitasking capability of Lucid CommonLisp 3.0, provides an easy way to implement the multiple autonomous processes required for IA’s. While all experiments, to date, have been done on Sun4 workstations, the system can be directly ported to other hardware platforms (e.g., DEC Stations 3100 and 5000) running Lucid 3.0.

In our initial prototype, all IA’s are restricted to run within a single workstation, though they can remotely access the MKS model and enterprise-wide information through the distributed MKS knowledge service protocols [2]. Future generations of the system will be fully distributed. IA’s will live on a variety of geographically dispersed workstation environments (C++, Lisp, Unix, VMS and so forth), communicating via the IA protocols, which are implementation independent. A host of distributed system issues must be addressed, however, to ensure that the protocols are routed efficiently and reliably to the appropriate recipients. Consider, for example, that messages may be directed toward a specific addressee, the current occupant of a job role, or a generic service provider, and that these agents may reside on any networked machine. A distributed infrastructure, itself based on low-level agents known as Proxies, is being developed for this purpose [PROXIES] and will soon be in place to support both the MKS knowledge service and a fully distributed version of the IA system.

v. EXAMPLES OF RUNNING AN “INTELLIGENT” ENTERPRISE WITH U S

We shall now illustrate through two examples how Intelli- gent Agents can be used to model and run enterprises. The first example is drawn from our actual ongoing experiments in automating semiconductor fabrication at CIS. The second example is a scenario, illustrating extensions of the model to other enterprise functions. Additional experiments using the MKS framework to coordinate design and manufacturing decisions for concurrent engineering are reported in Brown ~ 9 1 .

A. Automating Semiconductor Fabrication

Semiconductor fabrication is a complex enterprise involving numerous tasks and a variety of players-people, wafers, equipment and so forth. In the following scenario, which is a slightly dramatized version of currently running code, we focus on a few generic tasks such as routing wafers through processing steps, assigning equipment, and monitoring for equipment malfunctions. Tasks are modeled by a combination

r


of IA’s and AIA’s, with a few PA’s for situations where human involvement is necessary or desirable’. Simplicity and modularity were important desiderata in setting up our models, since we wanted them to be understandable and reusable. However, since all modeling implies engineering judgement, our particular decomposition of tasks into agents is not unique.

The action begins when the operations manager starts a new wafer lot. At the same time that a wafer lot is started in the fab-line, a “shadowing” wafer-lot genie will be created in the IA world. This wafer-lot AIA is entrusted with shepherding the lot expeditiously through the process recipe, always looking out for its best interests (e.g., making sure it is on schedule). As explained in Section 111-B, the lot’s AIA routes its wafers through the fabrication line following the road maps defined in the process recipe. At each process step, it performs dynamic equipment assignment by selecting the most suitable equipment (e.g., capable and least busy) among all available machines in the fab-line [2]. The wafer-lot AIA subsequently sends an IA-message to the chosen equipment’s operator IA, requesting that the lot be added to the incoming waiting queue of the equipment. The wafer-lot AIA then switches itself to the so called “holding-in-queue” state (as shown in Fig. 4) where it awaits potential abnormal reports from other 1A’s (e.g., the equipment’s IA reporting that the machine is being shut down). It also wakes up periodically to make sure that its job request is not unfairly stalled in the equipment’s queue.

From a production perspective, each piece of equipment has an operator IA that maintains a waiting queue for incoming lots and is responsible for keeping its machine running at peak efficiency. Whenever the equipment is in an “idling” state, its operator IA will attempt to select a wafer lot from the waiting queue following a given prioritization rule, and instruct the equipment to load and process the lot. At the completion of the process, the lot is physically unloaded from the equipment, and at the same time, an IA message reporting the completion of the step is sent from the equipment IA to the lot’s genie. In response to the message, the lot’s genie will resume active control of the lot and continue pushing it through the process recipe. Basic production management is thus achieved in a distributed fashion through interactions between wafer-lot AIA’s and equipment-control IA’s. Fig. 8 is a snapshot of WIP (work-in-process) tracking in progress on the MKS facility monitor display. It shows a simulated production process in the CIS photolithography area, in which wafer routing and equipment assignment were accomplished in a distributed fashion through negotiations among IA’s representing wafer lots and processing/testing equipment3.

Agentized equipment monitors (i.e., equipment’s monitor ZA) further demonstrate the flexibility and naturalness with which IA’s can systematically capture and automate complicated enterprise operations. Each equipment’s monitor IA emulates a technician watching for anomalous sensor read- ings (including gauges, instruments, and measurements). For

2Human involvement may be necessary because the reasoning underlying a task is too hard to automate, or simply because a person is needed to manually adjust control knobs on a machine

3A production simulator was used for this phase of our experiments because the CIS laboratory does not have regularly scheduled production runs.

Fig. 8. An example of IA-based distributed production control.

example, the Tylan-monitor, IA discussed in Section III- 2, continually tracks the health of the furnace, watching for an abnormal temperature gradient indicative of a leak. If a malfunction is detected, an IA-message requesting an emergency shutdown of the equipment will be sent to the Tylan furnace’s operator IA (and if an acknowledgment from the targeted IA is not received within 120 s, a doomsday alarm will be forwarded directly to the Facility-Manager’s PA). In response to the shutdown message, the operator IA will refer to knowledge in the activity object to determine the best way to execute the order. Possibilities include issuing a direct electronic command to the furnace, and if this cannot be done, sending a message to the PA of the operator-on-duty (e.g., Mary’s PA), which should know the best way to alert that person (e.g., activating a personal beeper). Additionally, an IA- message will be sent from the operator IA to the AIA’s of all wafer lots that were either awaiting or undergoing processing on that furnace. The AIA of the wafer-lot currently in process must decide if the lot can be salvaged, either through rework or adjusting the recipe at a subsequent processing step, or whether it should be simply scrapped. For any lot that is waiting in the equipment’s queue when the failure occurs, its AIA will have to locate another qualified machine and register to get on its waiting queue. Finally, the monitor IA will attempt to locate a maintenance person on duty who can repair the equipment. This can be done by putting out an open bid-call in the IA network within CIS, requesting Tylan furnace repair service at the cheapest “price” (as defined by an associated cost function), as shown in Fig. 5. If no one responds on time, a message will be sent to the facility manager instead.

B. Extensions to Other Enterprise Functions

The above methodology extends directly to enterprise functions beyond the shop Boor. At an enterprise level, instead of pushing wafers through a fabrication line following a recipe, one pushes paper and electronic forms through company departments (sales, marketing, purchasing, engineering,


shipping and so forth) following an information flow model and organization chart. The analogy between smart forms and smart wafers is clear. An AIA could shepherd a customer’s order through sales, negotiating with the Sales Manager’s IA Tor early delivery. The Sales Manager’s IA, in turn, might then negotiate with an Engineering Manager’s IA to schedule engineering time for a desired product customization, and with the Production Manager’s IA to schedule actual production. The Production Manager’s IA might contact suppliers and subcontractors about delivery times, the Shipping Manager’s PA about scheduling transportation, and so on. Finally, during manufacture, the AIA overseeing the original order can watch out for schedule slippages. At an even higher level of the enterprise, the corporate VP of Finance’s IA could keep watch over aggregate cash flows, and the VP of Marketing’s IA could track sales trends.

Such an extensive enterprise-wide model would, of course, have to built incrementally. One might begin with a skeletal model of the major activities, assembled from published job descriptions and official responsibilities obtained from organization charts. Initially the skeletal model would be very incomplete, so much routine work would still have to bc referred to humans via their PA’s. However, over time, individuals would gradually transfer routine responsibilities to IA’s, thereby fleshing out the model, and moving toward a more equitable man-machine partnership.

VI. DISCUSSION

A. Summary

We have presented a framework in which human and intelligent agents can interact to facilitate the information flow and decision making in real-world enterprises. Underlying the framework is the notion of an enterprise model that is built by dividing complex enterprise operations into a collection of elementary tasks or activities. Each such task is then modeled in cognitive terms and entrusted to an IA for execution. Tasks that require human involvement are referred to the appropriate person through their Personal Assistant-humans and IA’s thus participate in the framework as equal partners.

Our preliminary experimental results suggest that this strategy of dividing complex enterprise activities into many simple cognitive processes that conform closely with real tasks, is a viable approach to real-world distributed AI. As Minsky [20] and others have observed interesting and complicated mental behavior can arise from the interactions of large numbers of simple agents. As the wafer scenario in Section V-A demonstrates, the same phenomenon occurs with IA’s at an enterprise level as well.

Our use of cognitive models that faithfully capture real tasks ensures that the resulting models will be natural and intuitive to the individuals responsible for those tasks. Whether the models are shallow (i.e., expressed as experiential rules) or deep (i.e., expressed in terms of goals, plans and beliefs) is not a primary concern. Indeed, while our experience suggests that many daily activities are readily expressed as shallow models, the IA framework does not preclude the use of deeper knowledge. The

real concern is that the models be comprehensible. Given the appropriate CASE tools and activity libraries, each individual in an enterprise can then build, debug, and maintain their own models of the activities with which they are personally most familiar. Because no formalization of corporate policies and procedures will ever capture completely the way an organization really works, we believe that this grass-roots, incremental modeling approach is the only practical way to integrate a complex enterprise.

B. Implications

Enterprise integration demands an incremental solution to automation. Our IA approach addresses this issue in a fundamental way by enabling men and machines to work together effectively as peers. As peers, they are interchangable by design, permitting an enterprise to be computerized incrementally, one job at a time, without impeding ongoing operations. IA’s thus provide a graceful and acceptable way to migrate from a people-based to a machine-based enterprise.

Viewed as an integration technology, the principled model- based approach provided by IA’s offers many advantages over traditional, ad hoc point-to-point and data-based integration solutions. For example, IA’s can bridge existing islands of automation by using SQL queries to interact with disjoint databases in several departments, just like a human would. However, IA’s can go further, encapsulating software packages and databases so that they are accessible directly via IA protocols. Such IA’s can then serve as intelligent front ends, actively soliciting opportunities to provide services. They can be programmed to recognize when their software client has something to contribute, initiate and supervise a run, screen the results, and notify other IA’s as appropriate. For databases, IA’s can serve the role of librarian, screening information requests for relevance, reformulating high-level queries into primitive formal search commands, and performing necessary post processing to return useful answers. While others are beginning to develop integration frameworks built around enterprise models [21], their models lack the distributed, active, cognitive flavor that allow IA’s to provide services such as the above.

We believe that the IA approach has the potential to transform the nature of corporate work in fundamental ways. At a minimum, enterprise operations can be made much more organized and efficient because one can afford to dedicate agents to perform hundreds or thousands of watchdog, expe- diting, and liaison tasks that would be prohibitively expensive if performed by people. It is exciting to contemplate the radical impact on enterprise productivity that could result if every enterprise entity (e.g., every wafer, customer’s order, engineering change) had a “free” IA assigned to look after its interests. Two long-term consequences are the likely elimina- tion of unnecessary “paper-pushing’’ and supervisory jobs and the attendant streamlining of organizations.

Even more significant are the potential business and eco- nomic benefits. Extending the IA network beyond a single company to encompass suppliers, subcontractors and cus- tomers, creates an Electronic Kiretsu, that could transform the

~

1406 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS, VOL. 21, NO. 6, NOVEMBEWDECEMBER 1991

nature of commerce. For example, IA brokers could create efficient electronic markets for products and services that are too inexpensive or too geographically dispersed to broker manually. Similarly, IA liaisons could make cooperative business or design ventures more effective by ensuring that everyone is kept informed of decisions that affect them.

C. Future Work

Our immediate plans are to conduct large-scale IA experiments at CIS, in which IA’s will be used to support a wide-variety of manufacturing operations. Subsequently, we will seek opportunities for testing the IA framework in industrial settings. In preparation, we are continuing to populate the activity library, while evolving a more formal and more sophisticated high-level vocabulary for activity modeling. We are also defining more sophisticated IA protocols for requesting services, negotiating, delegating, making commitments, and so forth. Concurrently, we are developing interactive CASE tools that would permit a distributed community to build and debug activity models [2], and enforce their consistency.

The preliminary experiments reported in this paper skirt some central DAI research issues, which will have to be addressed in future work. Foremost among these is the issue of how performance scales with increasing numbers of agents. The experiments reported in Section V were relatively small- scale, involving tens of IA’s running on a single processor. At such a scale, it is relatively straightforward for IA’s to locate each other and for the system to manage the assignment of computational resources to run agents. When the number of IA’s grows to hundreds or thousands, distributed over many heterogeneous systems, message routing and agent management become major research issues. For this reason, we are developing the open, heterogeneous, distributed IA infrastructure cited in Section IV [18]. An interesting feature of this proposed infrastructure is that it is, itself, agent-based. At the lowest level, primitive agents will use capitalistic protocols to purchase computational resources as well as services from each other. These primitive agents can then be organized in various hierarchical and matrix structures to facilitate basic agent management functions such as re- source allocation, reporting, delegation, authority, security and so forth. On this infrastructure, we will implement information agents that provide communication and information services to IA’s, enabling them to interact via IA protocols, oblivious to the complexities of distributed systems. IA’s will direct their requests for information and services from other IA’s to an information agent. It is that information agent’s responsibility to locate the appropriate recipients of the message and physically route it to them. In so doing, information agents will have to exchange information among themselves about the capabilities and information needs of their IA clients in order to avoid network-choking indiscrimi- nate broadcasts. They will also need to avail themselves of utility services provided by other information agents, such as the electronic equivalents of white- and yellow-page directory services, advertising and brokering services and so

forth. And they will need to perform information management functions such as determining who is allowed to see and change data, and when something needs to filed. We specifically want to explore implementing such information management tasks using IA’s that model how humans perform them.

A second issue involves competence in cooperative distributed problem solving. A central theme of CDPS research concerns the effective control and coordination of agents working on interacting subproblems, where each agent has only partial knowledge and where communication costs or bandwidth are bounded [8]. Such problems have proved to be among the most challenging in AI. Although some sophisticated techniques for multiagent planning and negotiation have been demonstrated, there have been virtually no real- world applications. In contrast, the pragmatic approach taken in IA research has addressed real-world CDPS tasks from the outset, sidestepping many of the complexities that have stymied DAI researchers. This apparent paradox deserves a closer look, as it holds lessons for both future DAI and IA work.

One explanation is that most of the initial activities we have chosen to model and automate with IA’s have not required sophisticated problem solving and negotiation. While there are certainly many enterprise tasks that could benefit from such sophistication, the important lesson is that many everyday activities can be accomplished with only primitive reasoning. Indeed, most human organizations are designed (or have evolved) to minimize precisely the type of agent interactions that dominate DAI research. Wherever possible, departmental responsibilities are partitioned so that their tasks are largely independent. Essential interactions are structured to make them tractable, for instance, by providing explicit channels for reporting and resolving conflicts.

Increasingly, corporate communication and information sharing are facilitated by information technology, such as shared databases. Similar facilitation is available to IA’s through the MKS knowledge service. Indeed, in the simple scenarios studied to date, IA decisions were coordinated largely through the MKS notification mechanism. In more complex scenarios, additional IA’s may need to be introduced to explicitly manage the IA decision making process. Consistent with our philpsophy, these IA managers would ideally model roles played by human managers in actual organizations. However, there is nothing to preclude a system designer introducing an IA manager that has no human counterpart, thereby creating an IA-assisted enterprise that is more efficient than the original.

A final explanation for the practicality of IA’s is their cooperative man-machine problem solving approach. In our system, as in any well-designed man-machine environment, tasks that exceed the automated problem solving capabilities of an IA are deferred to a human superior. Clearly, IA’s with more sophisticated reasoning abilities would enable more of a firm’s activities to be automated. In principal, smarter IA’s could also accelerate and improve organizational decision making by taking into account more knowledge and constraints than humans are able to process. We will therefore work


closely with others in the CDPS community to establish a set of common, tested protocols that will enable interactions between IA’s and other forms of intelligent agents. Such protocols would encourage other DAI researchers to integrate their agents into our IA framework and thereby gain access to rich, real-world experimental domains.

More sophisticated agents reduce, but do not eliminate, the need for human interaction; there will always be the need for a human “safety valve.” We will thus continue to emphasize a cooperative man-machine approach, employing problem solving models that are comprehensible to people. In this endeavor, we hope to join with researchers in the area of computer-supported cooperative work [3], [13]-[16], [22], [23], to combine their multimedia collaboration tools with our Personal Assistants. For example, when a PA refers some matter to a person for a decision, it should be smart enough to also bring up on that person’s workstation any required background information. If the matter requires a video teleconference to resolve, the same agent could help schedule the meeting (presumably, by delegating the task to an appropriate IA) and then support the meeting by providing shared access to on-line information. Ideally, one’s PA should support all their information-related activities in an integrated way.

In closing, one might ask why the above research topics, which involve collaborations with researchers in such diverse fields as distributed systems and CSCW, are relevant to distributed AI? Simply put, it is our belief that such an interdisciplinary approach is precisely what is needed for distributed AI to have a major impact on mainstream information technology.

ACKNOWLEDGMENT

The authors gratefully acknowledge our colleagues, J. Glicksman and B. Hitson of Enterprise Integration, P. Losleben of CIS, and Victor Lesser, a Stanford visitor from the University of Massachusetts, for their stimulating comments and constructive critiques.

REFERENCES

J. Y.-C. Pan, J. M. Tenenbaum, and J. Glicksman, “A framework for knowledge-based computer-integrated manufacturing,” IEEE Trans. Semicond. Manufact., vol. 2, pp. 33-46, May 1989. J. Glicksman, B. L. Hitson, J. Y.-C. Pan, and J. M. Tenenbaum, “MKS: A conceptually centralized knowledge service for distributed CIM environments,” (to be published in J. Intelligent Manufact., 1991). T. Winograd and F. Flores, “Understanding computers and cognition: A new foundation for design,” Norwood, NJ: Ablex, 1986. pp. 220, (paperback issued by Addison-Wesley, Reading, PA, 1987). J. Y-C. Pan and J. M. Tenenbaum, “PIES: An engineer’s do-it-yourself knowledge system for interpretation of parametric test data,” AI Mag., vol. VII, no. 4, pp. 62-71, Fall 1986. P. Dishaw and J. Y-C. Pan, “AESOP: A simulation-based knowledge system approach to CMOS process diagnosis,” IEEE Trans. Semicond. Manufact., vol. 2, no. 3, 1989. L. P. Kaelbling and S. J. Rosenschein, “Action and planning in embed- ded agents,” Robotics and Autonomous Systems, vol. 6, nos. 1 and 2, June 1990. C. Hewitt, “Offices are open systems,” ACM Trans. Office Inform. Syst., vol. 4, no. 3, pp. 271-287, July 1986.

E. H. Durfee, V. R. Lesser, and D. D. Corkill, “Cooperative distributed problem solving,” The Handbook of Artificial Intelligence, vol. IV, A.B. Barr, P. Cohen, and E. Feigenbaum, Eds. Reading, PA: Addison Wesley, 1989, pp. 83-147. N. J. Nilsson, “Action nets,” in Proc. Rochester Planning Workshop: From Formal Systems to Practical Systems, J. Tenenberg, et al., Eds., Univ. Rochester, Rochester, NY, 1989. J. S. Rosenschein and M. R. Genesereth, “Deals among rational agents,” in Proc. 9th IJCAI, 1985, pp. 91-99. Y. Shoham, “Agent-oriented programming,” Tech. Rep. STAN-CS- 90-1335, Stanford Univ., 1990. W.A. Kornfield and C. Hewitt, “The scientific community metaphor,” IEEE Trans. Syst., Man, Cybern., vol. SMC-11, no. 1, Jan. 1981. M. J. Stefik, G. Foster, D. G. Bobrow, K. Kahn, S. Lanning, and L. Suchman, “Beyond the chalkboard: Computer support for collaboration and problem solving in meetings.” Commun. ACM, vol. 30, no. 1, pp. 32-47, Jan. 1987. T. W. Malone, K. R. Grant, F. A. Turbak, S. A. Brobst and M. D. Cohen, “Intelligent information sharing systems,” Commun. ACM, 1987, vol. 30, pp. 39@-402. K. Y. Lai, T. W. Malone, and K. C. Yu, “Object lens: A ‘spreadsheet’ for cooperative work,” ACM Trans. Offie Inform. Syst., vol. 6, Oct.

J. Conklin and M. L. Begeman, “gIBIS: A tool for ALL REASONS,” J. Amer. Soc. Inform. Sci., vol. 40, no. 3, pp. 200-213, 1989. R. G. Smith, P. S. Bartb, and R. L. Young, “A substrate for object- oriented interface design,” in Research Directions in Object-Oriented Programming, B. Shriver and P. Wegner, Eds. Cambridge, MA: MIT Press, 1987, pp. 253-315. B. Hitson, “Distributed infrastructure for a prolific manufacturing enterprise,” in Proc. Hawaii Int. Con$ System Sciences, Jan. 1991. D. R. Brown, M. R. Cutkosky, and J. M. Tenenbaum, “Next-cut: A second generation framework for concurrent engineering,” to appear in Computer Aided Cooperative Product Development, D. Sriram and R. Logcher, Eds. M. L. Minsky, Society of Mind. New York, NY: Simon and Schuster Pub., 1986. D. Beekman, “CIM-OSA Computer integrated manufacturing-Open system architecture,” Int. J. Computer Integrated Manufact., vol. 2, no. 2, pp. 94-105, 1989. I. Greif Ed., Computer-Supported Cooperative Work: A Book of Read- ings. San Mateo, C A Morgan Kaufmann, 1988. M. H. Olson Ed., Technological Support for Workgroup Collaboration. Hillsdale, NJ: Lawrence Erlbaum Associates, 1989.

1988, pp. 332-353.

New York Springer-Verlag, 1991.

Jeff Yung-Choa Pan (A’89-M’90) received the B. S. degree in electrical engineering in 1973 from the National Taiwan University and the Ph.D. degree in computer science in 1984 from the University of Illinois at UrbanaKhampaign.

He is a co-founder of Enterprise Integration Tech- nology Corporation, where he collaborates with Stanford University in a joint research program on Technology CAD (TCAD) and computer-integrated manufacturing (CIM) technology for semiconductor manufacturing. Previouslv. he worked at the

Fairchild Laboratory for Artificial Intelligence Research (FLAIR), which was later reorganized into Schlumberger Palo Alto Research (SPAR), where he led research projects in developing artificial intelligence techniques for enhancing manufacturing productivity. In 1989, he was a Visiting Scholar at the Center for Integrated Systems, Stanford University, Stanford, CA, representing Schlumberger Technologies, where he also managed the Schlumberger research team collaborating with CIS researchers in developing techniques for integrating software modules throughout a manufacturing enterprise.

Dr. Pan is a member of the American Association for Artificial Intelligence and of the ACM. His research interests include qualitative modeling and research, diagnosis, knowledge-based automation, and integration techniques for manufacturing and other enterprises.

1408 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS, VOL. 21, NO. 6, NOVEMBERDECEMBER 1991

Jay M. Tenenbaum received the B.S. and M.S. degrees in electrical engineering in 1964 and 1966, respectively, from the Massachusetts Institute of Technology, Cambridge, MA, and the Ph.D. degree in electrical engineering and computer science in 1970 from Stanford University, Stanford, CA.

He is a co-founder of Enterprise Integration Tech- nology Corporation, Palo Alto, CA, a research and development and consulting organization that de- velops sophisticated information architectures for information sharing, decision coordination, work-

flow automation, and electronic commerce. In 1980, he co-founded the Fairchild Laboratory for Artificial Intelligence Research (FLAIR), which was later reorganized into Schlumberger Palo Alto Research (SPAR), serving as its director from 1983 to 1986. In 1986, he returned to active research, after being appointed a Schlumberger Fellow and Professor of Computer Science (Consulting) at Stanford University. From 1988 to 1990, he served as Director of Advanced Research Projects for Schlumberger Technologies. At Stanford, his research focused on applications of artificial intelligence in design and manufacturing.