An autonomous agent development environment for engineering applications

Advanced Engineering Informatics 19 (2005) 123–134 www.elsevier.com/locate/aei

An autonomous agent development environment for engineering applications Qi Hao*, Weiming Shen, Zhan Zhang Integrated Manufacturing Technologies Institute, National Research Council of Canada, 800 Collip Circle, London, Ont., Canada N6G 4X8

Abstract Agent technology is playing an increasingly important role in developing distributed, intelligent, and collaborative engineering applications. The innate difficulties of interoperation between heterogeneous agent communities and rapid development of multi-agent systems have motivated the emergence of FIPA specifications and the proliferation of multi-agent system platforms or toolkits that implement FIPA specifications. This paper presents a FIPA compliant multi-agent framework called Autonomous Agent Development Environment (AADE). Originating from the engineering fields, AADE can facilitate the rapid development of collaborative engineering applications (especially in engineering design and manufacturing fields) through the provision of reusable packages of agent level components and programming tools. An agent oriented engineering project on the development of a collaborative product design environment is implemented based on the facilities provided by AADE. Crown Copyright q 2005 Published by Elsevier Ltd. All rights reserved. Keywords: Agents; Multi-agent systems; Collaborative environments; Product design

1. Introduction Complex engineering design projects generally require the cooperation of multidisciplinary design teams and the readily accessibility of various engineering tools, such as CAD, FEA, dynamic and kinematic analysis, and simulation packages. However, the significant investments and highdemanding expertise of these engineering tools hinder the small and medium enterprises from acquiring their design and engineering competencies. Apart from economical considerations, other forbidding factors in product design and engineering process include: – The time consuming nature of product design and engineering process, which may contain design loops, iterations, choice between alternatives, design optimization, etc.; – Heterogeneous and geographically distributed engineering software tools, personnel, knowledge, and engineering data; * Corresponding author. Tel.: C1 519 430 7149; fax: C1 519 430 7064. E-mail addresses: [email protected] (Q. Hao), [email protected]. ca (W. Shen), [email protected] (Z. Zhang).

– Inherent difficulty in efficient management of multiple design projects, each of which may further include multiple versions of engineering data; – File formats transformation and physical transport of large volume engineering data. In order to coordinate engineering design activities in a design project and guarantee the integration of different engineering tools, it is very important to have an efficient collaborative design environment. This environment should not only automate individual tasks, in the manner of traditional computer-aided engineering tools, but also meditate between individual tasks to promote collaboration within the context of a design project. Agent based systems represent one of the most promising computing paradigms for the development of distributed, open and intelligent software systems [1]. Agent technology has been widely applied in the engineering design field since the early 1990s. There is a plethora of literature on the application of software agents in the design field, such as PACT [2], SHARE [3], DIDE [4], Co-Designer [5], and A-Design [6]. A comprehensive survey on agent applications in intelligent design and manufacturing and a recent

1474-0346/$ - see front matter Crown Copyright q 2005 Published by Elsevier Ltd. All rights reserved. doi:10.1016/j.aei.2005.05.007

124

Q. Hao et al. / Advanced Engineering Informatics 19 (2005) 123–134

review of projects related to conceptual design could be found in [1,7]. During the past several years, we have been working on the development of collaborative environments for multidisciplinary design optimization (MDO) and developed a prototype software environment-WebBlow (a Web/agent based blow molded parts design and optimization environment) [8–10]. In WebBlow, a multi-agent system is used to integrate blow molding process simulation, performance simulation and optimization algorithms. However, the development of an agent based industrial application is not an easy task. In building an agent based application, developers unavoidably meet the challenge of insufficient support of agent level infrastructures. On the other hand, in spite of the technical difficulties in developing multi-agent systems, the interoperability between heterogeneous agents and agent systems is also very important. If one system does not interoperate with others, the general applicability of the system in the engineering fields cannot be assured. For the above reasons, the major objective of Foundation of Intelligent Physical Agents (FIPA) [11] has been targeted to promote the interoperability of heterogeneous agents and agent systems. Moreover, with the mature of FIPA specifications and the proliferation of FIPA compliant agent platforms and toolkits, the applications of agent technologies in industries are promisingly foreseeable. However, no one existing FIPA compliant agent platform or toolkit can easily be applied to develop engineering applications. Based on comprehensive studies on FIPA specifications, agent platforms, and agent applications, as well as more than ten years experience on the development of agent based engineering design and manufacturing systems, we developed a light-weighted FIPA compliant agent framework called Autonomous Agent Development Environment (AADE). It is worth pointing out that originating from the perspective of engineering, the basic facilities provided by AADE are open, flexible and scalable, and are expected to accelerate future research and development in agent based applications in design and manufacturing. The rest of this paper is organized as follows: Section 2 introduces FIPA standards and compares three well-known agent platforms that implement FIPA specifications; Section 3 presents the architecture of AADE, its main components, and the distinguished characteristics; Section 4 describes the system architecture of the agent based collaborative design and engineering environment, its composed agents, and the developed software prototype based on AADE; Section 5 concludes the paper with our contributions and future considerations.

2. FIPA compliant agent platforms Agent is a higher level abstraction in software engineering. Agent based approaches alleviate the high

coupling of distributed objects by using a message passing communication paradigm. In a multi-agent system, an agent is characterized by its autonomous and cooperative capabilities, such as independent reasoning and local decision making, handling incoming messages and managing multiple tasks at the same time. However, the agent technology seems to be too complicated for practical applications without the provision of essential components that form the baseline for agent system development process. Moreover, for many reasons, agents developed by different organizations are difficult to interoperate because of the lack of a common messaging and ontology interface. FIPA [11], founded in 1996, is an international standardization organization promoting the development and specification of agent technologies. The main goal for FIPA specifications is to specify how different kinds of agent platforms can interoperate. In the context of FIPA, an agent is an encapsulated entity with its own states, behavior, thread of control, and an ability to interact and communicate with other entities-including people, other agents, and legacy systems [12]. FIPA offers a set of application independent specifications which have covered almost all the topics concerning agent technology, including agent life cycle management, agent communication, ontology, agent mobility and security. Basically, FIPA abstract architecture specifies: in the directory facilitator (DF), a yellow page functionality to support service registration and discovery; in the agent management system (AMS), a white page functionality to enforce agent naming service and agent life cycle management; and in the message transport service (MTS), the default communication method between agents on different agent platforms or within the same platform. MTS may include an advanced message routing functionalities (agent communication channel, ACC) on top of single or multiple message transport protocols (MTP, such as HTTP and IIOP). Fig. 1 shows the abstract architecture of FIPA specifications. MTS is a flexible part which could vary from one agent platform to another. Some platforms use the MTS to handle only the cross-platform messages and let agents within the same agent platform communicate directly; while some other platforms use the MTS to handle all messages running both inside and outside its residing agent platform. FIPA specifications have reached such a maturity that FIPA compliant agent systems have been implemented by various developers. More than one hundred agent toolkits or platforms have been developed and presented in the literature or on the Web, with different mixes of mobility, adaptability, intelligence, ACL and multi-language support [13]. Among them, three well known agent platforms are: JADE [14,15], FIPA-OS [16,17] and Zeus [18,19]. Using agents as the unit of encapsulation, all these three agent platforms can provide an agent code base that liberates developers from the laborious work of building basic agent

Q. Hao et al. / Advanced Engineering Informatics 19 (2005) 123–134

Software

Agent Platform 1 Agent Management System

Agent

Directory Facilitator

Message Transport Service

MTP

ACC

ACC

125

However, working with a specific agent platform has some drawbacks. First of all, the code is portable only if delivered with the host platform (e.g. JADE). Second, the limitation of documentation and licensing problem hinder its adaptability to engineering applications. Many industrial customers would like to protect their intellectual property, which could not be guaranteed by codes under open-source agreement. Third, the code efficiency is also a serious problem. Because the purpose of these agent platforms is simply to break down general agent from domain related problems from the viewpoint of computer science discipline, this target may not be balanced and optimized to fit special requirements of engineering applications. In this paper, we present an FIPA compliant agent framework proposed and developed particularly for engineering applications.

Message Transport Service Agent Platform 2 Fig. 1. FIPA abstract architecture.

infrastructures and thus improves the quality, reliability, and interoperability of agent applications with great cutdown of the development time. Table 1 presents an evaluation of JADE, FIPA-OS and Zeus. More information about FIPA and non-FIPA agent construction tools can be found in [20]. Comparisons of agent platforms from various facets can also be found in [12,21,22].

3. Autonomous Agent Development Environment (AADE) AADE is an engineering oriented agent framework that provides agent based engineering application developers with reusable agent oriented classes (templates) which share useful relationships. To build the framework, the agent level issues and domain dependant ones must be identified and programming abstractions must be encapsulated. Based on our investigation on the FIPA specifications and the existing agent frameworks that implement FIPA specifications, we

Table 1 Evaluation of JADE, FIPA-OS and Zeus JADE

FIPA-OS

Zeus

Developer License FIPA support Development tools

TILAB (formerly CSELT) LPGL FIPA 2000 N

Emorphia/Nortel Networks open source FIPA 2000 N

Debug and monitoring tools

RMA, Sniffer, DF GUI

Main components

Agent container, message queue, behavior, scheduler

Message transportation protocols

Interactive protocols and conversation management

Java RMI; IIOP; serialized Java object Message queue; ACL message template Composite behaviors; behavior engine

API for debugging messages, viewing threading pools, monitoring task execution, etc. Agent shell (MTS, task manager, conversation manager) and factories (database, parsers) Java RMI; IIOP

British Telecom Labs open source FIPA97 Agent generation tool, graphical agent role definition Society viewer, reports tool, agent viewer, agent control tool, statistical tool Mailbox, message handler, execution monitor, co-ordination engine, scheduler TCP/IP Socket

Agent co-ordination

N

Multi-task execution scheduling

Central scheduling mechanism; round robin

Agent mobility

Y

Message handling and routing

No support for customized message routing Conversation manager, conversation, task manager, task, task event and task state N Distributed scheduling mechanism by message, conversation and task manager listeners N

Mailbox, message handler, message templates and routing rules Agent co-ordination engine; conversations Y. multi-tasking represented as recursive FSM Central scheduling mechanism; agent co-ordination engine N

Q. Hao et al. / Advanced Engineering Informatics 19 (2005) 123–134

expect that our agent framework could benefit from the characteristics of JADE, FIPA-OS, and Zeus. For the rapid prototyping of a collaborative product design and engineering environment in an industrial case study, the current version of AADE only implements a semantically closed agent community in which all agents communicate with each other within the agent framework using a dedicated content language expressed in XML. Fig. 2 shows the agent abstraction model in AADE, which is somewhat similar to other agent architectures in the literature. This agent model in AADE can be envisaged as a nonexclusive modular model. In a non-exclusive modular model, software modules (entities) confined in different boxes can access or utilize each other directly across their boundaries. These relationships between modules could be too complicated to draw in one single diagram. However, in the view of object encapsulation, these relationships can be hided behind the external interfaces of Java classes.

3.1. Communication package The lower level agent communication is conducted through a peer-to-peer transport protocol, TCP/IP socket. The Communication Interface module is implemented by two independent threads: a SocketListener and a SocketSender to handle the data stream flowing both ways in the specified communication sockets and the messages in the message queues. Mechanisms of message routing, message payload encoding and decoding, envelope processing are also implemented in the communication package as basic facilities.

Problem Solving Thread

DataBase

Messaging Package Interaction Protocol / Conversation Control

ACL Parser

Conversations

General Function Package Registration

Schedules

Agent Management

Utility Package

Common Interface

FTP Client

Database / File / email

Exception & Logging

Files

Knowledge Base

User

Message Handling

Application

QSent QOutBox QInBox QReceived Message Queues

SocketSender (Thread)

Communication Interface

Socket Listener (Thread)

Communication Package

Learning / Reasoning / Problem Solving

Execution Thread

User Interface

Main Thread

As shown in Fig. 2, the agent infrastructures or common functionalities are abstracted and associated with each agent role. There are four major packages developed in AADE. The following subsections describe these packages as well as other domain dependant modules, and briefly discuss the important features of AADE.

Application Interface

126

XML Parser

Zipping

eMail

Fig. 2. Agent abstraction model in AADE.

Q. Hao et al. / Advanced Engineering Informatics 19 (2005) 123–134

The Message Queues module intends to accomplish functions of message buffering and scheduling in an agent. Four kinds of message queues are handled together by this package: QInBox, QOutBox, QReceived and QSent. The two socket communication threads mentioned above are basically linked with QInBox and QOutbox and the inner movements of messages among these boxes are processed in similar ways as regular email handling systems. Simple matching mechanisms are developed in the SocketListener to collect basic information (i.e. Sender, Date, Receiver, etc.) and to make sure that only the expected messages are passing to its Message Queues.

127

STATES: 1: conversation start 2: waiting for the first-run reply 3: waiting for the second-run reply 4: conversation end

1

send Request

receive Refuse

2 receive Failure receive Agree

receive Inform-Done

4

3.2. Messaging package FIPA defined 22 communicative acts (performatives) and 11 interaction protocols so that agents can interact under a universal message oriented communication language. In AADE, we only implement a subset of these communicative acts based on the interaction protocols chosen for the related engineering applications. The most frequently used protocol is the FIPA Request protocol (Fig. 3). It is worth noting that the FIPA performatives are used to describe the exchanged message types between agents and Agent Universal Modeling Language (AUML) [23] is used to model the conversation (protocol).

Initiator

Paricipant

request

refuse [refused]

agree [agreed and notification necessary] failure

3

receive Inform-Result Fig. 4. FSM diagram of FIPA Request initiator.

As shown in Fig. 2, the Message Handling module deals with the payload of messages that are represented in FIPA ACL, while the Conversation Control module maintains a conversation list, enforces the sequences of FIPA protocols, and controls the states of conversations. Because the content in ACL is represented by the XML format, the corresponding ACL Parser is responsible for understanding the meaning of content in message payload after the XML parser (in Utility package) distilling the payload information. The sequences of agent interactions are represented separately as Finite State Machine (FSM) diagrams for each agent roles. Taking FIPA Request protocol as an example, there are two agent roles participated in this protocol: the Initiator and the Participant. While the sequence diagram in Fig. 3 provides a society level view of interaction, the state machine charts in Fig. 4 represent the internal processing sequence of the agent performing the Initiator role. This FSM based conversation control mechanism is very powerful and because of its generality, all kinds of FIPA protocols and even the user-defined protocols can be easily expressed using this kind of abstraction. Through the representation of FSM, the ‘data’ model and ‘control’ mechanism of protocols can be separated, making the protocols easily definable and the protocol management modules reusable.

inform-done: inform

3.3. General function package inform-result: inform

Fig. 3. FIPA request interactive protocol.

By referencing FIPA management specifications, we abstract general functionalities that all agents commonly share with. These functionalities are packed as the General Function package. The directory facilitator (DF) is a component in AADE that provides the white pages and yellow pages directory services to all other agents. It is an agent that combines

128

Q. Hao et al. / Advanced Engineering Informatics 19 (2005) 123–134

the functionalities of AMS and DF described in FIPA. The responsibility of Registration module is to handle registration functions on both sides of agents (either DF agent or agents other than DF). The agent identification (AID), including agent name and its transport descriptions, is registered to the DF agent. In particular, special information of agents representing engineering resources (PS Agents as described in Section 4) is included in agent’s configuration file to enable an agent to register its engineering capabilities (domain dependant) as well. The operations concerning registration process include: register, deregister, modify, search, pushRegistry and the leaseTime control mechanism. Among these operations, only pushRegistry is not specified in FIPA. We designed this operation originating from the DF to other agents to push the new updates of agent registry to all agents listed on the current registration table. From implementation point of view, the major difference between pushRegistry and other operations is that it is implemented through a one-way message rather than a complete conversation. Because the system does not need to check and guarantee whether the receiver could actually get the updates, the workload of system and network is significantly reduced. Similar to the Registration module, Scheduling and Agent Management modules provide supports for regular software maintenance (such as backup, restore, logging and exceptions, from the viewpoint of software engineering) and overseeing the transition of agent states in multiple conversations (from the viewpoint of agent engineering), respectively. The specifications of FIPA agent management system (AMS) are partially implemented to meet the requirements of agent lift cycle management in AADE.

interface may differ from agent to agent depending on the types of agents. Some are just for monitoring purpose and others may require menus or buttons for user’s intervention. Sophisticated user interfaces may provide intelligent assistance to users [24]. However, all kinds of user interfaces can still be quickly built up by using the common components in the Utility package. In our case study, a number of commercial or selfdeveloped engineering software tools are to be wrapped as corresponding problem solving agents (PS agent) (details described in Section 4). As a result, the AADE agent model has an Application Interface and a separate running thread for executing and monitoring a certain kind of engineering software tool. The Application Interface needs to be developed one by one according to the requirements of a real engineering project. The Learning/Reasoning/Problem Solving is the place to put an agent’s special intelligence in. According to its definition, an agent is usually a software system that enjoys at least the following properties: autonomous, cooperative, reactive, proactive, and rationality [25]. Each agent has its beliefs, knowledge, desires and intentions. In AADE, we include all the agent functions related to knowledge, learning, rule-based reasoning, casebased reasoning and domain dependant problem solving strategies in this composite block so that the development of agents could be simplified by customizing as less components as possible. 3.6. Important features The important features of AADE provide a foundation for the development of open, dynamic, flexible, and reliable (fault tolerant) multi-agent systems, which are very important for real world engineering applications.

3.4. Utility package Although agent is believed to represent a higher level of abstraction in software engineering, it still needs to possess basic functionalities that any software entity should have. In the utility package, we provide an agent with some software engineering facilities, such as database operations, file operations, FTP client, email handling, exception handling, logging operations, XML parsing, general interface components, and various zipping classes (for message security and encoding). 3.5. Domain dependant modules In AADE, application-specific agents can be constructed by customizing the interfaces of the generic agent model. The parts needed to be specialized are depicted as three dark blocks on the right side of Fig. 2. A User Interface is required for some agents to show its running state, incoming and outgoing messages, logging files, and so on to the human users. The user

3.6.1. Multi-threading Each agent deals with multiple threads at the same time to handle concurrent tasks. Fig. 2 shows briefly the threads that an agent in AADE should have using boxes with dark shadow. As mentioned before, two threads are committing to the socket communication, one thread takes care of execution of the wrapped external program, while the Main Thread and Problem Solving Threads take the roles of periodic scheduling, event-driven scheduling, coordinating, and domain-dependant tasks’ scheduling. 3.6.2. Multi-layered message frame and message handling The structure of message (messageFrame is used as a terminology in AADE) contains multi-layered information as depicted in Fig. 5. An AADE message envelope is added on the standard FIPA envelope to enable advanced messaging functions. For example, msgLevel is used to differentiate the priority level of a message so that urgent messages in the QInBox and QOutBox could be treated differently. Also the Responder could be used to specify

Q. Hao et al. / Advanced Engineering Informatics 19 (2005) 123–134

AADE Message Envelope

FIPA Message Envelope

FIPA ACL Frame

msgID msgTitle msgLevel sender responder .....

from to date encoding .....

performative protocol ontology reply With in Reply To

.....

ACL Content Fig. 5. AADE message frame.

the thread of the receiving agent if such information is known to the sender. With this mechanism, it is possible that messages are directed to (or pulled by) different threads of an agent. The true multi-threading can only be implemented with centralized message scheduling being eliminated as much as possible. Similarly, the message handling mechanism involves a multi-layered architecture. Fig. 6 shows the five layers of message handling in AADE. From bottom to top, they are: network layer, communication layer, message layer, conversation layer and problem solving layer. The reference relationships of these layers with related data structures are also shown in Fig. 6 on the right hand side. The good partition of software components demonstrated in AADE could benefit a feasible, flexible, reliable and maintainable multi-agent application system. 3.6.3. Peer-to-peer agent communication The lower level agent communication is conducted through a peer-to-peer transport protocol, TCP/IP socket.

Problem Solving Layer

Task List

Conversation Layer

Conversation List

Messge Layer

Message Frame

Message Queues

Fig. 6. Layered message handling.

This is a strategy that represents more precisely of the agent’s ‘loosely coupling’ and ‘autonomous’ concepts compared with the tightly coupled client-server RMI invocation used in JADE and FIPA-OS. The communication package is designed to be the internal functionalities of each individual agent rather than having a shared MTS to handle the intra-agent platform messages. In other words, we expect the MTS to deal with the cross agent platform messages only. 3.6.4. Originated from and serving to the engineering fields. Section 4 presents an example of using AADE to develop an agent based collaborative environment for product design and engineering. From this prototype, we could demonstrate the adaptability of AADE to engineering applications. The agent knowledge base, problem solving abilities, configuration file, registration information, and more specially, the inclusion of an engineering data management agent (EDM agent) could greatly accelerate the development process of engineering multi-agent systems. The related supporting facilities in Utility package contribute to this feature as well, such as facilities dealing with engineering files and file transportation (FTP client). Benefiting from the object oriented programming and component technologies, AADE provides reusable software libraries, interfaces and agent development templates that can be specified for agent implementation. Development tools that facilitate the development, configuration, debugging, monitoring and visualization of multi-agent systems are included in our future research and development plan. More features will be added to the feature list of AADE progressively.

4. A prototype for e-Engineering design and optimization This section presents our recent project on the development of a collaborative product design and engineering environment using agent and Web-based technologies. A case study used to validate the prototype environment is the design of a wheel-axle assembly (part of a bogie system). More information about this project as well as our long-term strategies of e-Engineering services paradigm can be found in [26]. 4.1. Prototype system architecture

Communication Layer Network Layer

129

The architecture of this prototype system for engineering design and optimization is shown in Fig. 7. It is designed and developed based on AADE. System functions include project management, job management, user management, engineering data management and system integration with different kinds of engineering software tools. A number of software agents have been designed.

130

Q. Hao et al. / Advanced Engineering Informatics 19 (2005) 123–134

Applciation / Web Client

e-Engineering Server Agent

Web Clent (Applet)

Servlet

Interface Agent

Database

EDM Agent

Engineering File System

Job Agent Task Agent Task Agent IRONCAD Design Client

Message Record Data

Monitor Agent Directory Facilitator

Registration Data PS Agent

IRONCAD PS Agent

PS Agent

PS Agent

Message Link Data Link

AFA

ANASYS

DADS

Data and Control Link

Fig. 7. Architecture of an agent based e-engineering design and optimization system.

4.1.1. e-Engineering server agent (ES agent) It is the gateway that users must get through to define, manage, and monitor the information about a design project and its affiliated design jobs. Therefore, all manipulations of engineering data related to the project, workflow, design job and tasks are done by the EDM agent (see below) through the ES agent. Every time when a design job starts running, the ES agent generates a job agent dynamically. The reverse process happens when the ES detects that a job has been finished. 4.1.2. Engineering data management agent (EDM agent) The EDM agent is a proactive engineering data service agent. EDM has the knowledge of database location, connection configuration, engineering file directories, and location and configuration of FTP server, etc. It provides database and file system operation services, such as creating

data sets for a new job, updating design data, retrieving design tasks, and helping send data files proactively to the target agents before a job starts. 4.1.3. Job agent (JA) A job agent communicates with the EDM agent for storing and retrieving job data; with the DF agent for searching matched PS agents; and with the problem solving agents (PS agent) for negotiation based design tasks’ allocation. A job agent is created and dissolved dynamically by the ES agent to control the design job it represents. 4.1.4. Directory facilitator agent (DF agent) It has all the registration service functionalities for other agents residing in this multi-agent system; keeps up-to-date agent registration and informs all registered agents with

Q. Hao et al. / Advanced Engineering Informatics 19 (2005) 123–134

updated registry; and provides lookup and matching-making services to job agents. 4.1.5. Interface agent (IA) User requests enter the agent system through the Webbased user interfaces. Several Servlets are responsible for receiving these requests on the Web server. The IA then catches the user requests from Servlets, translates the requests to messages, and initiates corresponding conversations to related agents. On the other hand, when the agent system reaches a result, the IA creates updates to user interfaces based on the replies from agents. So, the IA is a kind of application that functions mainly as a two-way bridge connecting the Web-based user interfaces and the back-end agent systems. 4.1.6. Problem solving agent (PS agent) PS is the actual engineering problem solving agent. A PS agent not only carries out the communication, negotiation functions on behalf of engineering software, but also executes the execution thread to do the related analysis, simulation or optimization based on the parameters provided by the EDM Agent. In this project, four engineering software tools are wrapped and integrated: IRONCAD v 6.0 (for 3D graphical modeling), DADS v 9.6 (for dynamic analysis), ANASYS v 7.1 (for structural analysis), and AFA (for fatigue analysis). Considering IRONCAD is a standalone interactive 3D modeling software tool which is difficult to execute automatically by the system, its representative PS Agent is treated differently as an empty node (shown as a dark circle in Fig. 7). In this special case, IRONCAD software must be installed on the designer’s local site. Its representing PS agent does not have the execution interface as other PS agents and the IRONCAD task is manipulated and submitted manually by the human user. 4.1.7. Monitoring agent (MA) MA is specially designed to facilitate the monitoring of agents’ behaviors in the multi-agent system. In a distributed multi-agent system, because information is distributed and controlled by each individual agent, it is necessary to have an agent that could accumulate information from various resources when required. Through this monitoring agent, dynamic ‘condition’ of the system, the behavior of this multi-agent environment as well as all individual agents can be conveniently monitored or reviewed through a graphical tool provided to the user.

131

C/CCC, FORTRAN, and Visual Basic, are also used for legacy systems integration. All agents are implemented on AADE. The EDM agent is implemented to integrate MySQLe as the primary database for the entire system. Server side modules are implemented on Apachee and Tomcate. The behaviors of agents in AADE can be monitored through two kinds of graphical interfaces of the monitoring agent (Fig. 8). Figure 8(a) represents the agent interactions using a sequence-style diagram. Analogous to the UML sequence diagram, messages between agents are displayed sequentially according to their times of occurrence. Agent interaction history can be easily traced from the top to the bottom by scrolling the right-hand scroll bar in the window. Information of messages and conversations are also associated with the graph for the convenience of monitoring. Another style of interface in Fig. 8(b) shows message interactions among agents as directed arrows. This interface is a dynamical one with only the current message is highlighted. Simple agent configuration tool is implemented for the agent construction process in AADE. However, advanced agent construction, monitoring and development tools are currently not available yet. A working prototype based on AADE is developed through several agent interaction scenarios. More detailed description about this prototype implementation could be found in [27]. Fig. 9 shows some screenshots of the developed prototype. Figure 9(a) is a project definition user interface. A ‘project manager’ can define the workflow of a design project (including its composed tasks, control points and their relationships) by specifying a predefined project workflow template. The purpose of defining the workflow-based project is to streamline heterogeneous activities in a multidisciplinary team so that distributed team members could collaborate on a project in an integrated environment. For legacy systems’ wrapping, we already developed a parametric interface built in IRONCAD using Visual Basic. Because IRONCAD does not provide parametric modeling functions, this interface supports the backend CAD modeler to complete parameter change over the wheel-axle CAD model. Our prototype system also provides a Web-based user interface for inputting similar parameters in the job definition of a project. Fig. 9(b) shows this Web-based job parameter input interface for the wheel-axle design problem.

4.2. Prototype implementation 5. Conclusions The software prototype environment is implemented on a network of PCs with Windows 2000/XP and Linux as well as SUN workstations with the SUN UNIX environment. Java is the primary programming language for system implementation. Other programming languages including

Agent based collaborative engineering applications require a powerful agent framework that could facilitate their developments and implementation processes. This paper presents a FIPA compliant agent framework called

132

Q. Hao et al. / Advanced Engineering Informatics 19 (2005) 123–134

Fig. 8. Screen shots of monitoring agent.

AADE developed at the National Research Council Canada’s Integrated Manufacturing Technologies Institute. Originated from the engineering fields, AADE has the characteristics of loosely coupled communication, multiple message queues handling, finite state machine based conversation control, and multiple-threading agent execution. Although our current implementation of AADE is simplified and light-weighted compared with other FIPA

compliant agent platforms, its architecture is open, flexible, and scalable for future extension. An agent based collaborative product design and engineering environment is designed and developed based on the facilities provided by AADE. The environment is developed based on several advanced technologies including software agents, Internet/Web, workflow, and engineering databases. The design and optimization of

Q. Hao et al. / Advanced Engineering Informatics 19 (2005) 123–134

133

Fig. 9. Screen shots of the prototype for collaborative design and optimization.

a wheel-axle assembly is chosen as an engineering case to validate the prototype software environment. Our ongoing work on improving the AADE includes: – communication services at the agent platform level for cross platform agent communication; – support for multiple message transportation protocols; – agent management services, including agent naming, resolving and manipulation services;

– comprehensive support for FIPA interactive protocols and performance studies; – agent generation tools, agent configuration tools and agent monitoring tools; – content symbolization and ontology services in engineering design and optimization field. As for the future development of the collaborative engineering environment, we would devote our efforts on the following aspects:

134

Q. Hao et al. / Advanced Engineering Informatics 19 (2005) 123–134

– intelligent problem solving capabilities built in each agent; – intelligent load balancing for design jobs; – intelligent load balancing for problem solving agents; – general wrapping technologies for easy integration of legacy engineering tools; – Web Services oriented architecture for e-Engineering design and optimization; – integration with other applications, i.e. agent based scheduling, and enterprise collaborations.

Acknowledgements We would like to acknowledge the important contributions of Kewei Li, a guest worker at National Research Council Canada’s Integrated Manufacturing Technologies Institute, in the development of the software prototype.

References [1] Shen W, Norrie DH, Barthe`s JP. Multi-agent systems for concurrent intelligent design and manufacturing. London, UK: Taylor and Francis; 2001. [2] Cutkosky MR, Engelmore RS, Fikes RE, Genesereth MR, Gruber TR, Mark WS, et al. PACT: an experiment in integrating concurrent engineering systems. IEEE Comput 1993;26(1):28–37. [3] Toye G, Cutkosky MR, Leifer L, Tenenbaum J, Glicksman J. SHARE: a methodology and environment for collaborative product development. in: Proceedings of the Second IEEE Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, Morgantown, WV, USA, 1993; p. 33–47. [4] Shen W, Barthe`s JP. An experimental environment for exchanging engineering design knowledge by cognitive agents. In: Mantyla M, Finger S, Tomiyama T, editors. Knowledge Intensive CAD-2. New York: Chapman & Hall; 1997. p. 19–38. [5] Hague MJ, Taleb-Bendiab A. Tool for management of concurrent conceptual engineering design. Concurrent Eng: Res Appl 1998;6(2): 111–29. [6] Campbell MI, Cagan J, Kotovsky K. A-Design: an agent-based approach to conceptual design in a dynamic environment. Res Eng Des 1999;11:172–92. [7] Wang L, Shen W, Xie H, Neelamkavil J, Pardasani A. Collaborative conceptual design: a state-of-the-art survey. CAD 2002;34(13):981–96. [8] Wang Y, Shen W, Ghenniwa H. WebBlow: a Web/agent based multidisciplinary design optimization environment. Comput Indus 2003;52(1):17–28.

[9] Shen W, Ghenniwa H. A distributed multidisciplinary optimization framework: technology integration. J Integrated Des Process Sci 2003;7(3):1–14. [10] Shen W, Hao Q. A service oriented integration framework for blow molded automotive parts design and optimization. in: Proceedings of SAE 2004 World Congress, Detroit, MI, USA, 2004. [11] FIPA Specifications. http://www.fipa.org/specifications/index.html. [12] Van Breukelen M, Ahluwalia AK, Netten B, Hamers J, Rogier J, Ricci A. Available and applicable agent technologies. Technical Report for Privacy Incorporated Software Agent (PISA), TNO TPD/Finsa, 2001. [13] Griss ML. Software agents as next generation software components. In: Heineman GT, editor. Component-Based Software Engineering: Putting the Pieces Together. New York: Addison–Wesley; 2001. [14] TILAB, JADE. http://jade.cselt.it/. [15] Bellifemine F, Poggi A, Rimassa G. Developing multi-agent systems with a FIPA-compliant agent framework. Software Pract Experience 2001;31(2):103–28. [16] Emorphia, FIPA-OS. http://fipa-os.sourceforge.net/. [17] Poslad S, Buckle P, Hadingham R. The FIPA-OS agent platforms: Open source for open standards. in: Proceedings the 5th International Conference on the Practical Application of Intelligent Agent and Multi-Agent Technology, Manchester, UK, 2000; p. 355–68. [18] BT, Zeus. http://more.btexact.com/projects/agents/zeus/. [19] Nwana HS, Ndumu DT, Lee LC, Collis JC. Zeus: A toolkit for building distributed multi-agent systems. Artif Intell J 1999;13(1): 129–86. [20] http://www.agentbuilder.com/AgentTools/index.html. [21] Fonseca SP, Griss ML, Letsinger R. Agent behavior architectures: A MAS framework comparison. in: Proceedings of the First International Conference on Multi-Agent Systems and Applications, Bologna, Italy, 2001. [22] Nguyen GT, Dang TT, Hluchy L, Balogh Z, Laclavik M, Budinska I. Agent platform evaluation and comparison. Technical Report for Pellucid 5FP IST-2001-34519, Bratislava, Slovakia, 2002. [23] AUML. http://www.auml.org/. [24] Wu S, Ghenniwa H, Shen W. User model of a personal assistant in collaborative design environments. In: Gero J, Brazier F, editors. Agents in design, 2002. p. 39–54. [25] Wooldridge MJ, Jennings NR. Agent theories, architectures, and languages: a survey. in: Proceedings of Intelligent Agents, ECAI Workshop on Agent Theories, Architectures, and Languages, Berlin, Germany, 1995; p. 1–39. [26] Hao Q, Shen W, Park S, Lee J, Zhang Z, Shin B. An agent-based e-Engineering services framework for engineering design and optimization. In: Proceedings of the 17th International Conference on Industrial and Engineering Application of AI and Expert Systems, Ottawa, Canada, 2004; p. 1016–22. [27] Hao Q, Shen W, Zhang Z, Park S, Lee J. Development of an e-Engineering Environment for Mechanical Systems Design and Optimization. In: Proceedings of the Eighth International Conference on Computer Supported Collaborative Work in Design, Xiamen, China, 2004; p. 251–8.