Developing intelligent manufacturing systems using collaborative agents

Developing Intelligent Manufacturing Systems Using Collaborative Agents
Weiming SHEN and Douglas H. NORRIE Div. of Manufacturing Engineering, The University of Calgary, Calgary, Alberta, Canada E-mail: [wshen | norrie]@enme.ucalgary.ca, URL: http://imsg.enme.ucalgary.ca/ Rob KREMER Dept. of Computer Science, The University of Calgary, Calgary, Alberta, Canada E-mail: kremer@cpsc.ucalgary.ca, URL: http://sern.cpsc.ucalgary.ca/CAG/
Abstract
Agent technology has been considered as an important approach for developing distributed intelligent manufacturing systems. This paper presents some preliminary results of our two ongoing research projects related to the development of a new collaborative agent system architecture for intelligent manufacturing systems. The main features of the proposed architecture are described; some domain independent mechanisms and components are briefly introduced; and a case study is presented. of agent-based manufacturing systems can be found in (Shen and Norrie, 1999). The extended version of this survey in HTML format with direct links to related web sites is also available at: http://imsg.enme.ucalgary.ca/publication/abm.htm. At the University of Calgary, a number of research projects have been undergoing since 1991. These projects include IAO (Kwok and Norrie, 1993), Mediator (Gaines et al., 1995), ABCDE (Balasubramanian et al., 1996), Metamorph I (Maturana et al., 1998), MetaMorph II (Shen et al., 1998), Agent-Based Intelligent Control (Brennan et al., 1997; Wang et al., 1998), and Agent-Based Manufacturing Scheduling (Shen and Norrie, 1998). Based on the results and experience from these research projects, two further projects are underway. One is focused on the development of a generic collaborative agent system architecture in order to support collaborating software agents by providing easy-to-use coordination services over the Internet. This is a joint research project between the Intelligent Manufacturing Systems Group (IMSG) in the Department of Mechanical and Manufacturing Engineering and the Knowledge Systems Institute (KSI) in the Department of Computer Science. The other project is also a joint project by IMSG and KSI, and relates to recent research on collaborative interface agents for agent-based manufacturing systems. The objective of this paper is to report preliminary results of these two ongoing projects.
1. Introduction
Global competition and rapidly changing customer requirements are forcing major changes in the production styles and configuration of manufacturing organizations. Increasingly, traditional centralized and sequential manufacturing planning, scheduling, and control mechanisms are being found insufficiently flexible to respond to changing production styles and highly dynamic variations in product requirements. The traditional approaches limit the expandability and reconfiguration capabilities of the manufacturing systems. The centralized hierarchical organization may also result in much of the system being shut down by a single point of failure, as well as plan fragility and increased response overheads. Agent technology provides a natural way to overcome such problems, and to design and implement distributed intelligent manufacturing environments. Recently, agent technology has been considered as an important approach for developing intelligent manufacturing systems (Shen and Norrie, 1999). A number of researchers have attempted to apply agent technology to manufacturing enterprise integration, supply chain management, manufacturing planning, scheduling and control, materials handling, and holonic manufacturing systems (Parunak, 1987; Parunak et al., 1997; Bussmann, 1998; Maturan and Norrie, 1996). An extensive state-of-the-art survey

The rest of the paper is organized as follows: Section 2 reviews some related agent system architectures proposed in the literature for agentbased manufacturing systems; Section 3 describes the collaborative agent system architecture; Section 4 discusses the application of the proposed architecture to intelligent manufacturing; Section 5 depicts a manufacturing scenario based on the proposed architecture; Section 6 presents our initial prototype implementation; and finally Section 7 give some concluding remarks and perspectives.
2. Related Work
Various agent system architectures proposed in the literature for developing agent-based manufacturing systems can be classified into two categories: the Federation approach and the Autonomous Agent approach. Three types of approaches have been proposed for the federation architecture: Facilitators, Brokers and Mediators. In the Facilitator approach, several related agents are combined into a group. The communication between agents takes place always through an interface called a facilitator. Each facilitator is responsible for providing an intermedium between a local collection of agents and remote agents, usually by providing two main services: (1) routing outgoing messages to the appropriate destinations; (2) translating incoming messages for consumption by its agents. CIIMPLEX (Peng et al., 1998) and PACT (Cutkosky et al., 1993) used this type of approach. Brokers (also called broker agents) are similar to facilitators with some additional functions such as monitoring and notification. Broker agents can be found in AIMS (Park et al., 1993) and CIIMPLEX (Peng et al., 1998). The Mediator approach is another type of federation architecture. Generally speaking, a mediator can be considered as a facilitator plus some additional functions such as coordination and learning. A detailed description of the mediator concept and architecture can be found in (Gaines et al., 1995). Some application examples in Intelligent Manufacturing can be found in (Gaines et al., 1995; Maturana and Norrie, 1996; Shen et al., 1998). Federation multi-agent architectures (the Facilitator approach, the Broker approach and the Mediator approach) are able to coordinate multiagent activity via facilitation as a means of reducing overheads, ensuring stability, and providing scalability. The federation approach promises to be a
good foundation upon which to develop open, scalable multi-agent system architectures (Genesereth and Ketchpel, 1994). The Autonomous Agent approach is a different approach. Usually, an autonomous agent should have the following characteristics: (1) it is not controlled or managed by any other software agents or human beings; (2) it can communicate/interact directly with any other agents in the system and also with other external systems; (3) it has knowledge about other agents and its environment; (4) it has its own goals and an associated set of motivations. DIDE used this approach for developing agent-based engineering design systems (Shen and Barthès, 1996). AARIA also used the Autonomous Agent approach, but with fixed negotiation protocols (Parunak et al., 1997). A combination of the above mentioned approaches as a hybrid architecture was proposed in MetaMorph II (Shen et al., 1998) for developing more flexible, modular, scalable and dynamic manufacturing systems.
3. A Generic Collaborative Agent System Architecture
This section discusses the motivations and objectives of our ongoing projects related to the development of a generic Collaborative Agent System Architecture (CASA), introduces briefly the initial CASA, main components of this architecture and communication in CASA. A more detailed CASA description is being reported separately.
3.1 Motivations and Objectives
Eight years research experience related to applications of agent technology in developing agentbased intelligent manufacturing systems have given us insight into requirements and key issues of agentbased manufacturing systems. An overview of related projects finished at the University of Calgary with a summary of several interesting techniques and mechanisms developed during these projects and a discussion of key issues has been written in a separate paper for this same workshop (Norrie and Shen, 1999). Based on our previous research results, a new general purpose Collaborative Agent System Architecture (CASA) and an Infrastructure for Collaborative Agent Systems (ICAS) are proposed and being developed for the following reasons:

a generic domain independent architecture is more reusable than a domain specific architecture; - several interesting techniques and mechanisms have been developed during our previous projects (Norrie and Shen, 1999), and they may become more interesting and useful when they are developed into domain independent modules and mechanisms; - emergent Internet technology and Java programming language allow us to develop agent-based systems in a different way than usual. Figure 1 shows an infrastructure for developing collaborative agent systems. It also indicates our basic ideas and motivations to develop a generic collaborative agent system architecture.
-
flexible framework must handle the complexity of the interaction and message passing. Some of the fundamental requirements of such a framework are: - R1: There must be one or more places where persistent data can be made publicly available for use by the agents. - R2: There must be one or more places to serve as "hubs" around which cooperative activity may center. - R3: There must be a service by which agents can find and join cooperative activity. - R4: There must be a service by which agents can find each other. - R5: There must be a service by which one agent may invoke a dormant agent (one that isn’t running).
3.3 Design and Implementation
Domain Specific Applications
Organization, Adaptation and Domain Independent Entities Other Domain Independent such as Ontology Server, KM Mechanisms Servers, User Interfaces Collaborative Agent System Architecture (CASA) (Communication, Cooperation and other Domain Independent Services)
The basic requirements listed in Section 3.2 are fulfilled by the components shown in the Figure 2. Each of these components is explained in more detail in the remainder of this section.
Internet/Intranet/LAN
Figure 1. Infrastructure for Collaborative Agent Systems
The generic Collaborative Agent System Architecture (CASA) is composed of collaborative elements such as agents, local area coordinators (LACs), yellow pages and cooperation domain servers. The objective of the CASA work is to support collaborative software agents by providing easy-to-use domain independent communication and cooperation services over the Internet. These services include conversation messaging services, lookup and search services, and remote call services etc. The provision of these services should significantly reduce the complexity of developing systems of collaborating agents.
Figure 2. CASA Components
3.4 Agents
Agents do not communicate with one another in an ad-hoc, point-to-point manner. Instead, agents working together form cooperation domains. Each agent in a cooperation domain routes all its outgoing messages through the cooperation domain server, which can direct it to a specific agent (imitating point-to-point communication), to several agents (imitating multicast communication), or to all agents in the cooperation domain (imitating broadcast communication). All incoming messages are received from the cooperation domain server as well (the original sender's identity is contained in the message
3.2 Requirements
In order to allow the easy construction of collaborative agent systems, a lightweight and

header). The benefit of all messages going through the cooperation domain server is that the server can then provide several services (described later) and agents can address roles and services, even if they don't know the identity of the agent or agents performing these roles or services.
specified service and may retrieve descriptions of those agents' locations. This partially fulfils requirement R4 (agents must be able to find each other) by providing a lookup service for agents.
3.7 Area and Local Area Coordinators
An area is a convenient quasi-physical division of the network that can be controlled by a local area coordinator (LAC). The area may be a single computer, some arbitrary division of a single computer, or a cluster of computers. A local area coordinator acts both as a representative of the area to the outside world, and a manager for the local agents within the area. If an agent (inside or outside the area) wishes to communicate with a specific agent (local to the area) it must get the local agent to join a cooperation domain. Since the local agent may not be active, there must exist some means of invoking it if necessary. The LAC takes on this role, which fulfils requirement R5. Any agent may send a message to the LAC to request that the LAC ask one of its local agents to join a particular cooperation domain. The LAC will invoke the agent if necessary, and pass along the request to the agent. Thus, the LAC fulfils the rest of requirement R4 (agents must be able to find each other) by facilitating connection initiation among agents. The LAC also facilitates local agent's communication to the outside world by providing an interface service to the outside world. Instead of each agent having to keep a model of network locations of servers and yellow pages, the LAC provides a central cache of such data. Local agents may query the LAC to obtain yellow page services; the LAC may, in turn, pass these requests to one or more known yellow pages and broker the responses. This simplifies network modeling requirements for individual agents. All ordinary agents reside in an area, and take advantages of services offered by the LAC. The CASA defines a minimal agent, which describes the minimum functionality of an agent participating in the architecture. A minimum agent must be able to communicate with its LAC and participate in a cooperation domain. Skeleton agent code is provided that implements this functionality.
3.5 Cooperation Domain Servers
The cooperation domain server listens to a specified port for new connections. Other agents may send requests to this port to create a new cooperation domain, or join an active or inactive cooperation domain. The server may allow this request by creating a new cooperation domain server (in the case of a new cooperation domain or a join to an inactive cooperation domain) and replying to the agent with the port number that the cooperation domain server will use. In addition, the server offers data storage services to the cooperation domain – storing and retrieving named stream data on request. Thus, the server and its cooperation domain servers fulfil requirements R1 and R3: data is persistently stored, and agents may find and join a cooperation domain. The cooperation domain server is the receiver of all messages sent by the agents in the cooperation domain. Although the exact content of the messages may be in any language (whether known or unknown to the server), all messages are in an extended KQML format (Finin and Labrou, 1997). Thus, the cooperation domain server can determine the ultimate destination and some of the high level semantics of the message. The cooperation domain server takes care of forwarding the message transparently to its destination, whether it is an individual agent, a list of agents, all agents of a particular service type (role), or all agents in the cooperation domain. In addition, the cooperation domain server may record all transactions to enable history playback and "group undo" operations. Thus, cooperation domain servers fulfil requirement R2 by acting as "hubs" around which cooperative activity is centered. A collaborative agent system may have one or more cooperation domain servers.
3.6 Yellow Page Agents
Yellow Page agents (also called Yellow Pages, or YPs) are responsible to accept messages for registering services and to record this information in a local database. Other agents may later query the yellow pages to determine what agents offer a
3.8 Communication in CASA
As mentioned in Section 3.4, communication in CASA is mediated by cooperation domain servers which can imitate inter-agent communication in three

different modes, i.e., point-to-point, multicast and broadcast. Such communication is implemented the Collaborative Agent Communication Language (CACL) that is developed by the same group. Initially, CACL allows for three simple actions: request, reply and inform. Messages are in an extended KQML format. More detailed descriptions of messages and dialogues used in CASA are reported separately in (Flores et al., 1999), and schema-based conversation modeling in (Lin and Norrie, 1999).
4. Other Domain Independent Mechanisms and Components
As described in Section 3.1, the main objective of CASA is to support collaborating software agents by providing easy-to-use domain independent services, which can be used to developing not only agentbased intelligent manufacturing systems, but also agent-based applications in other areas. However, our research focus is still on the applications of this architecture in developing intelligent manufacturing systems. The organization, adaptation and some other domain independent mechanisms as shown in Figure 1 have been separately proposed and developed during our previous research projects. We are now working on defining and developing several domain independent components such as collaborative user interface agents, high-level collaboration agents, knowledge management (KM) servers (or agents), ontology server(s) and so on. As shown in Figure 1, these components utilize the basic communication and cooperation services provided by CASA. All these components will become domain specific when implemented for a specific application and filled with domain specific information and knowledge. Detailed descriptions of these components are being written in separate reports and papers by other group members, and are also out of scope of this paper. However, we will give a brief introduction of these components here. Collaborative User Interface Agents Agents are often defined by their fundamental characteristics such as autonomous, communicative, collaborative, deliberative, reactive, pro-active, adaptive, etc, though agents in a specific multi-agent system do not have all these characteristics. We consider that (domain independent) collaborative
interface agents may have the following characteristics: - Communicative: able to interact with other agents through communication; - Semiautonomous: neither always under the control of humans or other agents, nor completely autonomous, i.e., humans should be able to control the amount of agent autonomy; - Collaborative: able to interact and collaborate with humans using structured natural language and other machine agents using speech act language (collaborative interactions allow interface agents to resolve conflicts and inconsistency in information, current tasks, and world models, thus improving their decision-support capabilities); - Reactive: able to react in a timely and appropriately manner to unforeseen events and to changes in its environment; - Pro-active: able to assist humans with the goal-directed behavior by taking the initiative; - Adaptive: able to accommodate changing user needs and task environments; - Self-aware: knows its own capability and the limit of its discretion, and then does not act over the limit. - Mobile: able to migrate through the Internet so that humans can open the interface, e.g., on a web browser, anywhere in the world (such interface is distinct from traditional web pages, it should be an interface agent with one or more of above mentioned characteristics). The development of collaborative interface agents is one of current research projects in our group, and the results will be reported separately (Matsumoto et al., 1999). High-Level Collaboration Agents Although several CASA components such as YPs and LACs also provide basic collaboration (cooperation) services, some complex large collaborative agent systems often need more highlevel and domain specific collaboration services which cannot be covered by YPs and LACs. In order to meet such requirements, the high-level collaboration agent is proposed as one of important components for ICAS. An example of this type of collaboration agent can be found the case study described in the following section, i.e., Production

Collaboration Agent. Such collaboration agents may be implemented by mediators as proposed and developed in our previous projects (Gaines et al., 1995; Maturana et al., 1998). In most cases, they are static, but they can also be implemented using dynamic mediators. Knowledge Management Agents Knowledge management is one of the most important issues in developing multi-agent systems. Typically, there are two approaches to knowledge management in multi-agent systems: - Knowledge is distributed among agents, i.e., every agent is implemented with a knowledge management module including knowledge acquisition, representation and reasoning mechanisms. This approach is widely used in autonomous agent systems. - Some knowledge management agents are used to centralize knowledge management. Despite some shortcomings of centralization, this approach has some advantages, e.g., it can facilitate knowledge acquisition and reduce communication overheads. It is very suitable for federated multi-agent systems and for the agent-based systems with a large number of agents, e.g., manufacturing production systems with resources being modeled as resource agents (Maturana et al., 1998). Our approach to this issue is to combine above mentioned two approaches, i.e., in addition to distribute some knowledge among agents, several knowledge management agents are developed for specific problems. A knowledge management agent is usually associated with one or more databases and knowledge bases. The key issues to develop knowledge management agents are to develop efficient mechanisms for knowledge acquisition, representation, learning and reasoning. Note that some simple knowledge management agents may be implemented by Yellow Page agents in CASA. Ontology Server An ontology is an explicit specification of a conceptualization. A conceptualization is an abstract, simplified view of the world that we wish to represent for some purpose. Since the set of objects and relationships in an agent are reflected in the representational vocabulary, an ontology can be given as a set of definitions for this shared
vocabulary. In the context of multiple agents, a common ontology can serve as a knowledge-level specification of the ontological commitments of a set of participating agents. A common ontology defines the vocabulary with which queries and assertions are exchanged among agents. The development and maintenance of ontologies require special formalisms and languages. Ontolingua (Gruber, 93) was developed to this purpose. Ontolingua allows one to define and to maintain ontologies by providing forms for defining classes, relations, functions, objects, and theories. Ontologies written in Ontolingua can thereby be shared by multiple users and research groups using their own favorite representation systems, and can be ported from system to system. As one of the important components for our proposed infrastructure, ontology server(s) will be developed using Ontolingua. The ontology server structure and related mechanisms are initially domain independent. It becomes domain specific when it filled with domain specific ontologies for a specific application, e.g., manufacturing production planning. Of course, it is not difficult to define the structure and mechanisms for an ontology server, but it is extremely difficult to develop and complete an efficient ontology server for an application domain. However, it has not been developed during our prototype implementation.
5. A Case Study – Production Planning
Based on the proposed architecture, domain independent mechanisms and components described in Section 4, a case study of manufacturing production planning is underway in our group. This section is entirely focused on description of this case study.
5.1 Conceptual Description
Background A distributed manufacturing enterprise with a headquarter (General Manager - CEO), a Production Planning Center (Production Manager), 2 Factories (each with a Factory Manager). Production Order and Product Data 100 products B with Due date D

-
One product B is composed of 1 part X, 2 parts Y & 3 parts Z One part Z has 3 manufacturing features (Fa, Fb, Fc), and needs 3 operations (Oa, Ob, Oc)
5.3 Description of Agents
The agents involved in the production planning scenario are described as follows (Figure 3): - IAc: Interface Agent designed for CEO - IAp: Interface Agent designed for Production Manager - IAf1 & IAf2: Interface Agents designed for Factory Managers 1 & 2 - C1, C2, C4 & C5: Collaboration Agent (implemented as LACs in CASA) - C3: Production Collaboration Agent - KA1: Knowledge Management Agent containing information like “who does what?” - KA2: Knowledge Management Agent containing information like “who to collaborate for task decomposition?” - KA3: Knowledge Management Agent having skills (capabilities) for product-level task decomposition (using information from a Product Model Database – DB1) - KA4: Knowledge Management Agent having skills (capabilities) for part-level task decomposition (using information from a Product Model Database – DB2) - PM1: Prototype Mediator (containing knowledge and data for creating dynamic mediators) - DM1: Dynamic Mediator for coordinating a
Factory 2
Factory Manager 2
5.2 Scenario at a Glance
CEO receives a Production Order A from some customer for 100 products B with delivery due date D; CEO sends the Production Order A to the Production Manager; Production Manager finds some competent agent for task composition, then the Production Order A is decomposed into parts production requests; Production Manager sends parts production requests to competent Factories for parts production; Factory Manager receives a part production request, finds some competent agent for further (sub-)task decomposition for decomposing a part production request into manufacturing features (with corresponding machining operations); Factory Manager negotiate with resource agents for machining operations, awards machining operation tasks to suitable resource agents, and then sends related information back to Production Manager.
Headquarter
CEO
-
-
-
-
Production Planning Center
Production Manager
6
Factory 1
Factory Manager 1
1 4
5 16 Virtual Cluster 1
IAc
2 3
IAP IAP
9 8 7
IAF1
15 14
IAF2
18 19 22
DM1
12 13
23 26 25
20
C5
TM1
24 21
C1
2 7 3
C2
8
C4 C3
11 9 10 17
DM2
RA1 RA2
DB2
RA3
??? KA1
KA2
DB1
KA4
KA3
Virtual Cluster 2
Figure 3. A CASA Scenario for Production Planning

-
-
group of factories DM2: Dynamic Mediator for coordinating a group of resource agents RA1, RA2, & RA3: Resource Agent 1 (A software agent used to model a manufacturing resource (e.g., a machine). It contains information about this machine’s capability, its plan, its cost ($/hour), … DB1: Product Model Database (Information about what parts does a product comprises) DB2: Product Model Database (Information about what manufacturing features does a part has)
message to KA3. Step 10: KA3 does the task decomposition (using the information from its Product Model Database – which is connected with a Product Modeling or Engineering Design System). The Production Order A (100 products B with due date D) becomes the Production Request A (100 parts X, 200 parts Y and 300 parts Z with due date D). Virtual Clustering Step 11: KA3 sends the Production Request A (100 parts X, 200 parts Y and 300 parts Z with due date D) to C3 for parts production. A Dynamic Mediator needs to be created for coordinating a group of factories (shop floors). As shown in Figure 3 with dashed lines, an alternative solution is that KA3 sends a reply with decomposed parts information to C4 which then forwards this reply to IAp. IAp then sends the Production Request A (100 parts X, 200 parts Y and 300 parts Z with due date D) to C3. This alternative solution may increase some communication, but it can ensure the stability and reliability of the system. Step 12: C3 sends a request for dynamic mediator creation to PM1 (Prototype Mediator) with the information about the Production Request A (100 parts X, 200 parts Y and 300 parts Z with due date D). Step 13: PM1 creates a Dynamic Mediator DM1 (Here DM1 needs get some information about IAf1 and IAf2. We assume here DM1 gets such information also from PM1.) A Virtual Cluster composed of DM1, IAf1 & IAf2 1 is created. Negotiation and Task Allocation
5.4 Operational description
Placing a Customer Order Step 1: After receiving a Production Order A (100 products B with delivery due date D), CEO places this order through the Interface Agent IAc. Step 2: CEO sends a request to C1 for asking “Who to collaborate for the Production Order A”; and C1 forwards this request to KA1. Step 3: KA1 finds the necessary information, and sends a reply “Contact IAp for Production order A” to C1 which then forwards such reply to IAc. An alternative solution is that KA1 sends directly the reply to IAc. Step 4: IAc sends the Production Order A (100 products B with due date D) to IAp. Step 5: IAp displays the Production Order A to the Product Manager at the Production Planning Center. Product-Level Task Decomposition Step 6: Production Manager places a request “Find agent(s) for task decomposition and factories (shop floors) for production” through Interface Agent IAp. Step 7: IAp sends a request “Who to collaborate for task decomposition” to C2 which then forwards this request to KA2. Step 8: KA2 finds the necessary information, and sends a reply “Contact KA3 for task composition” to C2 which then forwards this reply to IAp. An alternative solution is that KA2 sends directly the reply to IAp. Step 9: IAp sends the Production Order A (100 products B with due date D) (for task decomposition) to C3 which then forwards this
Step 14: DM1 sends out a Call for Bids for Production request A to IAf1 and IAf2. Step 15: IAf1 and IAf2 sends bids back to DM1: (IAf1: I can do 100 parts X and 200 parts Y by due date D. IAf2: I can do 200 parts Z by due date D and 100 more parts Z by date D4 (late)). Step 16: DM1 awards IAf1 and IAf2: (IAf1: Do 100 parts X & 200 parts Y. IAf2: Do 200 parts Z.) Step 17: DM1 subcontracts 100 parts Z by due date D to ??? Part-Level Task Decomposition & Allocation Step 18: After receiving the production request for producing 200 parts Z, IAf2 should find some agent(s) for part-level task decomposition (What

features does a part Z has?) IAf2 sends a request “Who to ask for part-level task decomposition” to C5. Step 19: C5 sends a reply to IAf2 “Contact KA4”. Step 20: IAf2 sends a request for part-level task decomposition “What features does a part Z has?” to KA4. Step 21: KA4 does the part-level task decomposition (using the information from its Product Model Database – which is connected with a Product Modeling or Engineering Design System): one part Z has three features Fa, Fb, & Fc. KA4 sends the results to IAf2. Another dynamic mediator needs to be created for coordinating resource agents RA1, AR2 & RA3. Step 22: IAf2 sends a request to DM1 for creating a dynamic mediator to form a virtual cluster for coordinating resource agents. Step 23: DM1 sends a request for dynamic mediator creation to PM1. Step 24: PM1 creates a Dynamic Mediator DM2, and also asks DM2 to “Contact IAf2 whose address is xxxx” for the information about resource agents. Step 25: DM2 sends a request to IAf2 for information about resource agents. Step 26: IAf2 sends a reply to DM2 with the information about resource agents RA1, RA2 & RA3. A virtual cluster composed of DM2, RA1, RA2 & RA3 is formed. Step 27: DM2 negotiates with resource agents RA1, RA2 & RA3 for manufacturing features Fa, Fb & Fc (correspondingly operations Oa, Ob & Oc) using the Contract Net Protocol (Call for Bids, Bids, Awards, …). When all operations are scheduled, DM2 sends an inform message to IAf2. Of course, IAf1 should do the same as IAf2 does for part-level task decomposition and allocation. When all tasks are allocated, IAf1 and IAf2 each sends an information message to IAp (for Production Manager) which then sends an inform message to IAc (for CEO).
management in collaboration with industrial partners. The main techniques and mechanisms proposed have been tested, and parts of the prototype have been separately implemented. The main programming languages are Java, C++ and Smalltalk. The operating systems under experiments include SUN UNIX, HP UNIX and Windows 95/98. This prototype implementation is being developed initially in simulation form.
7. Conclusions and Perspectives
This paper presents some preliminary results of our two ongoing research projects related to the development of a new collaborative agent system architecture, and furthermore a collaborative agent infrastructure, for intelligent manufacturing systems. The collaborative agent system architecture is initially proposed as a general architecture for Internet-based multi-agent systems. All components (including minimal agents, YP agents, LACs, cooperation domain servers, etc.) of this initial architecture are domain independent. This initial architecture has been extended by adding several domain independent mechanisms and components such as collaborative interface agents, knowledge management agents and ontology server etc. A prototype is being implemented in simulation form for a case of production planning. More extensive cases (e.g., supply chain management, etc.) are considered for proof-of-concept implementation. Industrial partners are being contacted for transferring simulation prototype to industrial applications.
Acknowledgements
Thanks to all other Collaborative Agent Group members for their contribution to the CASA development, and detailed discussions on the case study. These members include Bob Brennan, Roberto A. Flores, Fuhua Lin, Sudong Shu, Matsumoto Tsutomu, Mihaela Ulieru, Niek Wijngaards, Xiaokun Zhang, Bin Zhou.
6. Prototype Implementation References
A proof-of-concept prototype of the proposed architecture is being developed for the production planning case described in the previous section. Note that the case study described in Section 5 is not realistic. We are considering some realistic case studies for production planning and supply chain Balasubramanian, S., F. Maturana and D.H. Norrie (1996). Multi-agent planning and coordination for distributed concurrent engineering. International Journal of Cooperative Information Systems, 5(2-3), 153-179.

Brennan, R., S. Balasubramanian and D. H. Norrie (1997). Dynamic Control Architecture for Advanced Manufacturing Systems. In Proceedings of International Conference on Intelligent Systems for Advanced Manufacturing, Pittsburgh, PA, pp. 213-223. Bussmann, S. (1998). An Agent-Oriented Architecture for Holonic Manufacturing Control. In Proceedings of the First International Workshop on IMS, Lausanne, Switzerland. Cutkosky, M.R., R.S. Engelmore, R.E. Fikes, M.R. Genesereth, T.R. Gruber, W.S. Mark, J.M. Tenenbaum and J.C. Weber (1993). PACT: An Experiment in Integrating Concurrent Engineering Systems. IEEE Computer, 26(1), 2837. Finin, T. and Y. Labrou (1997). KQML as an agent communication language. In Software Agents, J.M. Bradshaw, (ed.), MIT Press, Cambridge, pp. 291-316. Flores, R.A., N. Wijngaards and R. Kremer (1999). Interaction Protocols for a Multi-agent System Architecture. Submitted to Agents’99 Workshop on Specifying and Implementing Conversation Policies. Gaines, B.R., D.H. Norrie and A.Z. Lapsley (1995). Mediator: an Intelligent Information System Supporting the Virtual Manufacturing Enterprise. In Proc. of 1995 IEEE International Conference on Systems, Man and Cybernetics, New York, IEEE, pp. 964-969.
Genesereth, M. and S. Ketchpel (1994). Software agents. Communications of the ACM, 37(7), 48-53.
Gruber, T. (1993). A Translation Approach to Portable Ontology Specification. Knowledge Acquisition, 5(2), 199-220. Kwok A. and D.H. Norrie (1993). Intelligent Agent Systems for Manufacturing Applications. Journal of Intelligent Manufacturing, 4, 285-293. Lin F. and D.H. Norrie (1999). Schema-Based Conversation Modeling. Submitted to Agents’99 Workshop on Specifying and Implementing Conversation Policies. Matsumoto, T. et al. 1999. Collaborative Interface Agents for Distributed Intelligent Manufacturing Systems. Submitted to ISAS’99. Maturana, F. and D.H. Norrie (1996). Multi-Agent Mediator Architecture for Distributed manufacturing. Journal of Intelligent Manufacturing, 7, 257-270.
Maturana F., W. Shen and D.H. Norrie (1998). MetaMorph: An Adaptive Agent-Based Architecture for Intelligent Manufacturing. International Journal of Production Research, (in press). Norrie, D.H. and W. Shen (1999). Applications of Agent technology for Agent-Based Intelligent Manufacturing Systems. Submitted to IMS’99. Park, H., J. Tenenbaum and R. Dove (1993). Agile Infrastructure for Manufacturing Systems: A Vision for Transforming the US Manufacturing Base. Defense Manufacturing Conference. Parunak, V.D., (1987). Manufacturing Experience with the Contract Net. In M. N. Huhns, (ed.), Distributed Artificial Intelligence, Pitman, pp. 285-310 Parunak, V.D., A.D. Baker and S.J. Clark (1997). The AARIA Agent Architecture: An Example of Requirements-Driven Agent-Based System st Design. In Proc. of 1 International Conference on Autonomous Agents, Marina del Rey, CA. Peng, Y., T. Finin, Y. Labrou, B. Chu, J. Long, W.J. Tolone and A. Boughannam (1998). A MultiAgent System for Enterprise Integration. In Proc. of PAAM'98, London, UK, pp. 155-169. Shen, W. and J.P. Barthès (1996). An Experimental Multi-Agent Environment for Engineering Design. International Journal of Cooperative Information Systems, 5(2-3), 131-151 Shen, W. and D.H. Norrie (1998). An Agent-Based Approach for Dynamic Manufacturing Scheduling. In Working Notes of the AgentBased Manufacturing Workshop, Minneapolis, MN, pp. 117-128. Shen, W., D. Xue and D.H. Norrie (1998). An Agent-Based Manufacturing Enterprise Infrastructure for Distributed Integrated Intelligent Manufacturing Systems. In Proc. of PAAM'98, London, UK, pp. 533-548 Shen, W. and D.H. Norrie (1999). Agent-Based Systems for Intelligent Manufacturing: A Stateof-the-Art Survey. Knowledge and Information Systems, an International Journal, to appear. Wang, L., S. Balasubramanian and D.H. Norrie (1998). Agent-based Intelligent Control System Design for Real-time Distributed Manufacturing Environments. In Working Notes of the AgentBased Manufacturing Workshop, Minneapolis, MN, pp. 152-159.