An intelligent agent framework for enterprise integration

  • Published on

  • View

  • Download



    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 manufac- turing 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 Us. Each IA supports a clearly discernible task or job function, automating what it can and calling on the services of other IAs when necessary. IAs 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 PAs), a special type of IA that knows how to communicate both with humans, through multimedia interfaces, and with other L4s 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.


    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 corpo- rate 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 IAs. Each IA supports a clearly discernible task or job function, automating what it can and calling on the services of other IAs, as well as human agents, when necessary. IAs 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 enterprises 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


    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.

    IAs model the perceptual, reasoning, action and commu- nication skills involved in performing human job functions, such as those of an equipment operator, production scheduler, engineer, purchasing agent or manager. IAs 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 IAs follow the established corporate lines of communication and procedures. Collectively, IAs 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 PAs). PAs belong to a special class of IAs 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, ones 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 IAs 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. PAs thus provide an element of completeness, enabling the modeling of activities that are too complex or too important to delegate to IAs. Moreover, PAs 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 IAs so that ultimately they can be performed interchangeably by a person or their agent.

    In addition to supporting traditional human activities, IAs 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 IAs as an inexhaustible source of cheap labor that can provide dedicated human-like services, 24 hours a day, ubiquitously throughout the enterprise. IAs 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 IAs 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 AIAs 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 IAs, MAs, and PAs 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 IAs, PAs 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 PAs that support current people-based styles of work. The initial PAs 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 IAs and their PA. IAs 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 IAs 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 PAs and IAs to protect them from drowning by dispatching routine matters autonomously.


    In the remainder of this paper, we flesh out this vision and describe a prototype implementation, currently under devel- opment, that will run the semiconductor fabrication facility at Stanfords 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.


    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 manufac- turing. 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 engineers 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 un- derlying 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 frame- work for sharing and coordinating information in a manu- facturing environment. MKS was based on the premise that many software applications in a given manufacturing envi- ronment 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






    / I \ (Supporting Applications)


    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 foun- dation of the enterprise integration framework depicted in Fig. 1. The editors shown in Fig. 2 can now be seen as early versions of PAs, and the applications as early versions of IAs. 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 IAs.

    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, IAs 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 IAs, 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 IAs at some length to underscore that our approach to agent research evolved independently from traditional distributed AI ap- proaches [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 IAs 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 Hewitts scientific community metaphor [12] plays a role similar to the MKS model, both facilitating agent interactions. The differences between IAs and other DAI paradigms are largely ones of cmphasis. The emphasis in our work is squarely on finding pragmatic approaches to cooperative, distributed problem solv- ing (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 en- able 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 Hewitts 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 so- phisticated agents and formal approaches. Indeed, IAs can be regarded as one of the first attempts to apply Hewitts conceptual framework to real organizations.

    A final distinction is that we are fundamentally committed to a cooperative man-machine approach to enterprise inte- gration. 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 IAs 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.


    A. Technical Overview

    The IA framework, illustrated in Fig. 3, consists of three synergistic technologies: intelligent agents, the MKS knowl- edge service, and a distributed system infrastructure (not shown). IAs interact with humans through their Personal As- sistants (PAs) over an enterprise-wide network using standard service protocols. IAs can also access information resources, control on-line equipment, and trigger other IAs 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, IAs 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 IAs, 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 represen- tation 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 IAs.

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



    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




    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, indi- vidual 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 fab- rication.

    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 de- fines 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 IAs 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 models internal state. PatternjAction rules specify what actions to take in response to sensory input patterns and IA messages, as a function of state.




    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 opera- tion): 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 spe- cific 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 Tylans and reused directly as a tem- plate 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 :


    ' 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> ;;its 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


    ;; 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:


    processing )


    ;; 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 )



    (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., equip- ment 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 operators 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 semi- conductor 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


    ..__________________------------------------------------------------------------ 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]:


    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 :


    ( > (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 IAs 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 agents 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 IAs 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 IAs 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 stim- ulus arrives, either as a symptom detected by one of the IAs 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 IAs 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 IAs. 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 comprehen- sive communication among IAs. Describing communications among IAs in this high-level vocabulary also insulates an enterprises 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 mes-

    sages 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


    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 com- mands 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 informa- tion 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 key- words 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.


    ;; 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) ;;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) ;;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)


    Fig. 7. Jeff encapsulated in his PA.

    ple as well as with other IAs. They encapsulate individuals, enabling them to interact with other IAs 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 indi- vidual 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)

    - IAs 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 IAs, 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, PAs, in principle, can be programmed to perform any task. The key to making PAs useful in an enterprise setting are the modeling tools and libraries of PA templates that make it possible for users to customize their own PAs. 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 ] .




    Our experiments with IAs 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. IAs 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 PAs 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 IAs. 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 IAs 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. IAs 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, how- ever, 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.


    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 IAs and AIAs, with a few PAs 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 lots 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 equipments 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 1As (e.g., the equipments 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 equipments 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 lots genie. In response to the message, the lots 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 AIAs and equipment-control IAs. 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 IAs representing wafer lots and processing/testing equipment3.

    Agentized equipment monitors (i.e., equipments monitor ZA) further demonstrate the flexibility and naturalness with which IAs can systematically capture and automate com- plicated enterprise operations. Each equipments 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 furnaces 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-Managers 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., Marys 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 AIAs 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 equipments 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 func- tions 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 com- pany 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 customers order through sales, negotiating with the Sales Managers IA Tor early delivery. The Sales Managers IA, in turn, might then negotiate with an Engineering Managers IA to schedule engineering time for a desired product customization, and with the Production Managers IA to schedule actual production. The Production Managers IA might contact suppliers and subcontractors about delivery times, the Shipping Managers 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 Finances IA could keep watch over aggregate cash flows, and the VP of Marketings 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 PAs. However, over time, individuals would gradually transfer routine responsibilities to IAs, thereby fleshing out the model, and moving toward a more equitable man-machine partnership.


    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 IAs thus participate in the framework as equal partners.

    Our preliminary experimental results suggest that this strat- egy 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 IAs 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 funda- mental 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 incremen- tally, one job at a time, without impeding ongoing operations. IAs 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 IAs offers many advantages over traditional, ad hoc point-to-point and data-based integration solutions. For example, IAs can bridge existing islands of automation by using SQL queries to interact with disjoint databases in several departments, just like a human would. However, IAs can go further, encapsulating software pack- ages and databases so that they are accessible directly via IA protocols. Such IAs 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 IAs as appropriate. For databases, IAs 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 IAs to provide services such as the above.

    We believe that the IA approach has the potential to trans- form 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, customers 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

  • ~


    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 man- ually. 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 ex- periments at CIS, in which IAs 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 pro- tocols for requesting services, negotiating, delegating, making commitments, and so forth. Concurrently, we are developing interactive CASE tools that would permit a distributed com- munity 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 IAs running on a single processor. At such a scale, it is relatively straightforward for IAs to locate each other and for the system to manage the assign- ment of computational resources to run agents. When the number of IAs 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 infor- mation agents that provide communication and information services to IAs, enabling them to interact via IA protocols, oblivious to the complexities of distributed systems. IAs will direct their requests for information and services from other IAs to an information agent. It is that information agents 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 di- rectory services, advertising and brokering services and so

    forth. And they will need to perform information manage- ment 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 IAs that model how humans perform them.

    A second issue involves competence in cooperative dis- tributed 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 so- phisticated 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 IAs 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 IAs 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 IAs 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 IAs 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, IAs with more sophisticated reasoning abilities would enable more of a firms activities to be automated. In principal, smarter IAs 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 IAs 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 persons 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, ones 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 dis- tributed AI to have a major impact on mainstream information technology.


    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.


    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 engineers 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 enter- prise, 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 (A89-M90) 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 semiconduc- tor 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, repre- senting 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.


    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.


View more >