Agent-based workflow management in collaborative product development on the Internet

COMPUTER-AIDED DESIGN Computer-Aided Design 32 (2000) 133–144 www.elsevier.com/locate/cad

Agent-based workflow management in collaborative product development on the Internet G.Q. Huang*, J. Huang, K.L. Mak Department of Industrial and Manufacturing Systems Engineering, The University of Hong Kong, Pokfulam Road, Hong Kong Accepted 2 September 1999

Abstract Product development is collaborative, involving multi-disciplinary functions and heterogeneous tools. Teamwork is essential through seamless tool integration and better co-ordination of human activities. This paper proposes to use workflow management as a mechanism to facilitate the teamwork in a collaborative product development environment where remote Web-based Decision Support Systems (TeleDSS) are extensively used by team members who are geographically distributed. The workflow of a project is modelled as a network. Its nodes correspond to the work (packages), and its edges to flows of control and data. The concept of agents is introduced to define nodes and the concept of messages to define edges. As a sandwich layer, agents act as special-purpose application clients for the remote TeleDSS application servers. Agents are delegated to manipulate the corresponding TeleDSS on behalf of their human users. Details of the proceedings are recorded by agents as their properties for future references or shared uses by other team members. Through flow messages, agents are able to share input and output data and request for remote services. One of the major contributions is that agents, once defined, can be reused for different projects without any changes. q 2000 Elsevier Science Ltd. All rights reserved. Keywords: Collaborative product development; Internet; Web; Agent; Workflow

1. Introduction A product development project consists of a set of work packages that in turn consist of activities and tasks. A team is established to conduct the project. Each team member may be responsible for one or more work package and/or activity. In addition, for each work package or activity, there may exist one computerised Decision Support System (TeleDSS) remotely available on the Internet accessible from Web browsers. Together with the corresponding TeleDSS, a team member is to accomplish his/her work package for which he or she is responsible. Project tasks and activities are interrelated. Therefore, team members must collaborate and corresponding TeleDSS must interact at some stage(s) of executing a project. The project team may be drawn from multiple corporations to form what is now called a Virtual Enterprise (VE). Alternatively, the team may be established within a single corporation but from different disciplines and functions. No matter, in a virtual or real enterprise paradigm, the team may well be distributed in the sense that they are geographically * Corresponding author. Tel.: 1852-2859-2591; fax: 1852-2858-6535. E-mail addresses: [email protected] (G.Q. Huang); [email protected] (K.L. Mak).

dispersed, diverse applications are involved, and the tools and systems used operate on different platforms using different protocols with different user interfaces. These have created great difficulties and hindrances in teamwork and tool integration required for Collaborative Product Development (CPD). This has challenged both industrialists and researchers over the last decade or so. Significant efforts have been made to develop computer supports to facilitate teamwork. Early developments and achievements in computer supported concurrent engineering had been reported in an American Society of Mechanical Engineers (ASME) workshop organised by Sriram, Logcher and Fukuda [24] and a special issue in the IEEE (Institution of Electrical and Electronic Engineers) Computer Journal (1993). Recent surveys by Huang and Mak [10] and Erkes et al. [6] indicate that the Internet/Web technology is playing increasing roles in developing and applying TeleDSS for CPD. Indeed, a number of major initiatives and projects, recently launched in America and Europe involving government, academic and industrial institutions, have adopted the Internet/Web technology as their development infrastructure. Examples include the Manufacturing Automation and Design Engineering (MADE) program and its follow-up Rapid Design Exploration and Optimisation (RaDEO) program [20], the Agile Infrastructure for

0010-4485/00/$ - see front matter q 2000 Elsevier Science Ltd. All rights reserved. PII: S0010-448 5(99)00096-2

134

G.Q. Huang et al. / Computer-Aided Design 32 (2000) 133–144

Fig. 1. The ActiveTeam architecture.

Manufacturing Systems (AIMS) project [1], the Technologies Enabling Agile Manufacturing (TEAM) program [25], the Global Engineering Networking (GEN) project [9], and Production Planning and Management in an Extended Enterprise (PRODNET) project [19]. More projects are emerging in other countries and regions. Demonstrative systems are being developed. CyberCut [23] and MADEFAST [5] were two well-known early experiments. Roy et al. [22] have also presented experimental workbenches for Web-based design to production, including activities such as conceptual and detail product design, process planning, Design for Manufacture, NC (Numerical Control) programming and rapid prototyping. Significant progress has been achieved in developing and applying Group or Team Decision Support Systems (GDSS). Web-based teamwork frameworks have emerged from two directions. One is from Computer Supported Collaborative Work (CSCW) and the other is from Workflow Management (WFM). The aim of applying the Web technology in CSCW is to develop Web-based framework or architecture to support teamwork or group decision-making. Participants are typically human users, rather than computer systems. One example of Web-based CSCW is the Web implementation of the GroupSystems methodology [21]. The Web technology has been applied for WFM. Resulting frameworks not only involve human participants

but also software systems. WebWork [14] is an example of Web-based WFM systems based on the METEOR WFM methodology. In parallel, research on Distributed Artificial Intelligence (DAI) has resulted in Multiple Agent Systems (MAS) that can be used for enabling Web-based CPD [17]. On basis of the findings from the research into agentbased collaborative engineering, CSCW, WFM, and Webbased DSS in product design and manufacture, this research proposes a Web-based framework to facilitate, rather than automate, teamwork in CPD where TeleDSS are extensively used at geographically distributed locations. This paper focuses on the aspect of WFM, including defining, co-ordinating and monitoring the flows of work, information and control between multiple TeleDSS. The concept of agents is proposed and incorporated into the workflow network model. The project workflow integrates the tools and team members towards a common goal of the product development project. It plays significant roles in facilitating better teamwork for CPD in a Web-based environment.

2. Web-based collaborative product development Fig. 1 shows a general Web-based architecture, ActiveTeam, proposed in the long term in this research to

G.Q. Huang et al. / Computer-Aided Design 32 (2000) 133–144

facilitate, rather than automate, better teamwork in CPD. It addresses a typical scenario that has been challenging both the academics and practitioners for many years. A project team is tasked with developing a product. Whether geographically distributed or co-located, team members are extensively assisted by a wide variety of Web-based TeleDSS remotely available and accessible on the Internet. Together with the corresponding TeleDSS, a team member is to accomplish his/her work package for which he or she is responsible. The team, as a whole, is faced with a challenge to better co-ordinate not only member tasks but also TeleDSS activities. As can be seen in Fig. 1 there are several main components in the proposed ActiveTeam architecture: • TeleDSS. Decision Support Systems in product design and manufacture that are remotely accessible on the Internet with standard Web browsers are referred to as TeleDSS. They are also called Virtual Consultants. They provide technical services relevant to the specific product development projects. • TeleCo tools. Tele-collaboration (TeleCO) tools are utility facilities of a virtual collaborative work environment that provides teams with a group-based desktop (or nettop) as a place to meet and work synchronously. Examples include whiteboard, chat, videoconference, and so on. • Workflow. A workflow describes a product development project in a network model. Its nodes represent the work (packages) and edges represent flows of control and data between work packages. • Agents. Following the client/server architecture, agents are client-side components of Web applications while TeleDSS are their servers. Agents form basic constructs of project workflow models. Agents are nodes while dependencies and messages between agents form the edges. Agent properties are persistent so that they can be shared and backtracked during collaborative sessions. In addition to above main components, there are several important repositories: • AgentBase is the repository for storing agent definitions. It is maintained by a server component, agentEngine. A client-side component, agentNavigator is also available for the users to define agent templates. • Agentboard is the repository for storing agent properties when they are executed. It is maintained by a server component, agentEngine. A client-side component, agentNavigator is also available for the users to activate agents interactively. • WfBase is the repository for storing workflow definitions. It is maintained by a server component, wfEngine in its editing mode. A client-side component, wfNavigator is also available for the users to define workflow models. While agent-based WFM is discussed in detail in Sections

135

3 and 4, the other two components, TeleDSS and TeleCO, are described briefly in Sections 2.1 and 2.2, respectively.

2.1. TeleDSS The Internet technology, World Wide Web (Web or WWW) technology in particular, offers a number of promising features to support remote DSS in product design and manufacture. The client–server architecture offers tremendous opportunities for the sharing of information among product development team members who may well be distributed in terms of both time and space. Because of the multimedia capability of the Web, Web-based applications provide functionality, performance and usability comparable to, if not better than, standalone applications. The Web technology has been applied or experimented to develop virtually all types of TeleDSS across the entire life cycle of the product development and realisation process. Starting from the front-end, the Web-based approach is particularly suitable for customer requirement management or market research. An interesting work at the Philips Advanced Development Centre is to use the Internet as a communication infrastructure for lead user involvement in the new product development process [16]. Another related project is to use the Web for customer requirement analysis for software product development [2]. From a wider perspective of supply chain management, the Web technology also has a great potential [15]. In design and manufacture, [26] experimented with developing fixture design systems on the Internet. Rapid prototyping is one of the areas where the Web technology has been applied [3,8]. Statistical Process Control (SPC) has also taken advantage of the Internet [7]. Krause et al. [13] employed the Web technology to achieve global product data management. In addition, the research groups of the authors are developing a suite of TeleDSS [10]. Examples include Web-based Quality Function Deployment (QFD), Failure Mode and Effect Analysis (FMEA), Design for Manufacture and Assembly (DFMA), Morphological Charts, Value Analysis, Rapid and Virtual Prototyping. TeleDSS can be made accessible within Web browsers when they are developed. However, they may have been built as standalone systems. Such existing standalone legacy systems are not usually readily accessible from the Web browsers on the Internet. They must be “wrapped” with “glue” codes. The resulting wrapped systems are accessible on the Internet, hopefully through Web browsers. In many occasions, wrappers, often called agents, also provide facilities to enable resulting systems to communicate with other applications, sending and receiving messages, files, etc. It is important to note, at this early point, that the research reported in this paper is not concerned with this wrapping process and such wrapping facilities or facilitators are not called agents. Software developers are assumed to have the responsibility of wrapping their systems.

136

G.Q. Huang et al. / Computer-Aided Design 32 (2000) 133–144

Fig. 2. The agent model.

2.2. TeleCO tools: TeleBoard and TeleChat Two of such TeleCO tools have been experimented and demonstrated. They are Whiteboard (TeleBoard) and Chat (TeleChat) facilities. The collaborators utilise chat and whiteboard tools in order to communicate various forms of information. With them, a team member could very quickly show the particular result under discussion to the rest of the team. The “free for all” policy is followed, that is, each user sees the same actions in the same order, and no action is ever rejected. TeleCO tools can be accessed through Web browsers. The user enters the URL (Universal Resource Locator) of the TeleCO tool in the client browser. The tool applet is downloaded to the client machine automatically. When the homepage of TeleCO tool appears on the browser, click the corresponding image hyperlink. The TeleCO Whiteboard frame appears. The user chooses the engineering drawing on which the team is working. Afterwards, the user can annotate the drawing with the line, rectangle, circle, and text tools provided by the whiteboard. Each user sees the result synchronously. A chat tool is also

integrated into the Whiteboard menu. When the chat frame window appears, users in a session can communicate through the text-based chat utility. 3. Agent-based collaborative product development This section introduces the concept of agents as used in this research project. Following the client/server architecture of Web applications, agents are their clients while TeleDSS are their remote servers. In addition to interacting with TeleDSS, agents are designed in such a way that they are capable of interacting with each other and recording their parameters or properties. 3.1. The need for agents The term “agents” has been widely used for building computer support for collaborative engineering. However, their functionality varies widely with different projects. For example, [11] and his research team have applied the concept of agents in collaborative product design and also developed a windows-based project network editor that

G.Q. Huang et al. / Computer-Aided Design 32 (2000) 133–144

links agent. Unfortunately, their agent-based workflow manager does not deal with Web-based applications. Most notably, the agent concept has been extensively used in major projects such as MADEFAST and CyberCut. Most participant systems included in these experiments were developed by third parties or by the same developer at different times. They are not normally interoperable. Solutions have to be devised to allow them to interoperate. One is to wrap them by specially developed software programs. As a result, wrapped application systems are called agents. Agents are interoperable in the sense that they are able not only to start and terminate each other but also to communicate with each other. Petrie [18] and Smith and Wright [23] explain how individual agents work and how they work as a community. When examined in detail, each agent may consist of a knowledge base, commuication and interaction module, and a set of optional functional components. Each agent has a knowledge base that contains the essential data and knowledge required by the agent to perform its activities. The communication and interaction module is responsible for sending and accepting messages to and from other agents in certain formats such as Knowledge Query and Manipulation Language (KQML) [12]. The same module is also responsible for transferring files needed by functional components, such as wrapped legacy applications, among agents. After they are registered in the central control agent, agents may communicate with each other. Each agent has an acquaintance list. It is a list of agents that the agent directly knows about. An agent can communicate only with those who are in its acquaintance list. The acquaintance list determines the interdependency and control structure among the agents. For example, the activities of the agents might be interdependent due to the constraint of ordering them in a certain order. Although the above agent concept has been widely demonstrated and tested, there are a number of serious limitations: • It may not be possible to specify the acquaintance list or define the messages when the legacy application systems are developed or wrapped. • Different product development projects involve different work packages and activities. Their supporting legacy application systems must therefore be wrapped differently. • Wrappers are usually introduced to enhance, to some extent to automate, the interoperation between participant systems. The fact that human users are frequently involved in the collaboration is not emphasised. • These multi-agent systems do not provide any facilities for interactively monitoring the progress of individual participants by their corresponding users although agents may send messages to enquire about the status of other agents. • A large number of TeleDSS are expected to emerge all

137

over the world in the near future. It would become increasingly time consuming and difficult to search for a DSS that is the most appropriate for a specific project or task, especially when their URLs (Universal Resource Locator) are unknown. General-purpose search engines such as Yahoo may not be helpful because most of the TeleDSS are not registered. 3.2. The agent model In order to resolve these difficulties, a new agent model is proposed in this research. This model is shown in Fig. 2. Several special considerations have been taken when devising the agent model. First, individual TeleDSS—remote application servers—do not usually communicate with each other directly at the time when they are developed. It is generally very difficult to re-code the application servers in order to allow them to communicate with each other. One solution, as used in MADEFAST and CyberCut environments is to wrap these TeleDSS to provide inter-system communication facilities. The resulting wrapped systems are referred to as agents in their work. A number of serious limitations have been outlined previously for this approach. This research favours an alternative solution. That is, the authors propose to achieve the interactions between application systems at the client or agent level, instead of at the level of the remote severs. This is based our experience that it is generally easier to write a new or modify an existing client-side component. Wrapping may be still necessary, especially when application systems are standalone legacy programs that cannot be used on the Web. In this case, the main purpose of wrapping is not to provide inter-system communication facilities, but to enable a client–server architecture on the Web, that is, to facilitate the interaction between the application server and client. The client component or agent is automatically downloaded not from the server machine where the TeleDSS server is deployed, but from the Web site where the agent is deployed, i.e. the agentNavigator Web server. In our proposed framework, interactions between applications are achieved by: (1) the interactions between application clients or agents; and (2) the interactions between the application servers and clients or agents. One of the main advantages of this approach is that developers of application servers do not need to concern themselves with inter-system communication during system design and development. Only the clients require some degree of customisation from the users’ perspective during agent definition. In addition, agents add a layer between TeleDSS and their human users. Together with other agents, human users are major sources of input data. For example, if an input property of an agent is directed at a user, then this user will be consulted for the value of this property when the agent and the associated flow are both activated. Therefore, the human factor is enhanced, rather than ignored in our agent model. Finally, the agentManager is a Web site as well. It

138

G.Q. Huang et al. / Computer-Aided Design 32 (2000) 133–144

provides facilities to assist system in registering their TeleDSS, and to assist manufacturing application software packages and analysts (team leader and members) in searching for the Web-based applications most appropriate for their project and work packages. The agentBase is a database for storing the definition details of agent templates. In addition, names and brief descriptions of TeleDSS, HTTP addresses, and/or their HTML file locations and names are registered in the agentBase. In terms of implementation, the agent-based system, agentManager, has two components. One is the client-side component, agentNavigator, and the other is the server-side component, agentEngine. They are deployed either at the same Web server or at two physically different Web servers. AgentNavigator is downloaded to client machines while agentEngine is executed and always remains at the server machine. All agentNavigator clients share the same agentEngine server object. Both components operate in two modes to support agent definition and execution. In the editing mode, agentEngine is mainly responsible for dealing with details of the agent definition. The associated database is agentBase. In the executing mode, agentEngine is mainly responsible for recording all the changes in agent properties in agentBoard.

3.3. Agent definition Agents must be defined before they can be used. Details of agent definition are stored in the agentBase. The definition process is accomplished by both the server-side component—agentEngine, and client-side component— agentNavigator. The definition of a new agent involves the following general activities: • The user uses the Web browser to connect to the Web server where agentNavigator is deployed. Upon connection, agentNavigator is downloaded to and executed at the client machine. • Facilities are provided in agentNavigator for the user to start defining the new agent in terms of its properties. • After specifying the necessary agent properties, the server-side component, agentEngine is contacted to record all the definition details of the new agent into the agentBase. This agent is then ready for future uses. There are several issues concerning the definition of agents. The first issue is who is responsible for defining the agents for the corresponding TeleDSS: the users or the developers. At this moment in our research, the user is assumed to have the responsibility of defining the agents although it is believed that systems developers would have better knowledge about their own TeleDSS. The second issue is when the agents should be defined. Basically, if the developers are responsible for agent definition, then they may define the agents when they register their TeleDSS. If the users are responsible, then they may

define agents when agents are used. That is, agents may be defined when the project workflow is defined. Finally, the agent model is meant to support the client developers more than server developers. Application clients may be developed without using the agent model. In this case, input and output data are not captured in agentBoard and therefore cannot be shared by other participant agents. Alternatively, an application client can be developed as a subclass of the agent model. The client inherits all the agent facilities. In this case, input and output data are always recorded in agentBoard. Such data may be used in the future to interact with other agents. 3.4. Agent execution Agents previously defined in agentBase can be retrieved to activate the specified TeleDSS. The execution process is accomplished by both the server-side component—agentEngine, and client-side component—agentNavigator. The execution of an existing agent involves the following general activities: • The user uses the Web browser to connect to the Web server where agentNavigator is deployed. Upon connection, agentNavigator is downloaded to and executed at the client machine. The execution mode is selected. • AgentNavigator contacts agentEngine to obtain a set of agents defined in the agentBase. • The user chooses the agent suitable for the task. • The chosen agent is executed. • The user supplies input data to the agent. • AgentEngine is invoked again to store the input data into the agentBoard for future references. • The agent calls for remote service (TeleDSS) according to the definition. • The remote service (TeleDSS) responds with a set of result data. • Output data are captured as the agent’s output properties. • AgentEngine is invoked again to store the output data into the agentBoard for future references. Application clients must have their user interfaces that must be reasonably sophisticated so that the logic of problem solving is reflected and the end user is able to follow the logic easily and consistently. The design of such user interfaces depends on the nature of the applications. A question now arises if agents themselves need a user interface. On the one hand, agent properties can be incorporated into the user interface of the application clients. In this sense, there is not need for agents to have their own separate user interface. As a result, the users need not to learn two user interfaces. On the other hand, it may be useful for agents to have their own primitive user interface independent of that of the application clients. The agent’s user interface is like the property page as used in the Microsoft Windows Explorer. The page describes the status of the

G.Q. Huang et al. / Computer-Aided Design 32 (2000) 133–144

agent. The page should be very straightforward to the end user. This research is in favour of an approach to developing application clients by sub-classing the agent model. In this approach, both agents and clients have their own separate user interfaces. The end-users usually use the client interface for usual applications. Experienced users use the agent interface when necessary to check the status of the agents. 3.5. Interoperation between agents and TeleDSS The Web technology has evolved rapidly. A number of methods have appeared for application clients and servers to interact with each other. Clients and servers are deployed as distributed components or objects following certain specification standards. Distributed objects operate across a heterogeneous network on different computers, living within their own address space outside of an application, and yet appear as though they were local to an application. Three of the most popular distributed object paradigms are Microsoft’s Distributed Component Object Model (DCOM), OMG’s Common Object Request Broker Architecture (CORBA) and JavaSoft’s Java/Remote Method Invocation (Java/RMI). A full discussion of these methods is beyond the scope of this paper. More details can be found in the literature [32] and previous experiences [30,31]. 4. Agent-based workflow management The preceding section has presented the agent model for the development of application client components. This section will investigate the use of WFM in supporting CPD and the roles of the agent model in this context. 4.1. The need for workflow management The need for better WFM in Web-based CPD can be dealt with through the following research questions: • Why is WFM suitable for the purpose of CPD? • Why and how does the Web technology complement the WFM technology? Let us look at the first question from two aspects. On the one hand, a product development project usually includes a set of work packages or activities that are executed by different personnel at geographically dispersed locations. At any time, different engineers may work on their own tasks that are interrelated to one another. The decisions made by one engineer may have significant impacts on those by other engineers. To prevent inconsistency and reduce redundant activities, engineers must collaborate effectively and efficiently and project activities must be well coordinated. Therefore, there is a clear need for a mechanism to accomplish the co-ordination. On the other hand, WFM technology has been promoted as a model of co-ordination or collaboration among work

139

centres, especially when Information Systems are extensively used. [28] identifies several possibilities of coordination such as output co-ordination, process and activity co-ordination, control co-ordination, and resource co-ordination. As a result, the technology has been applied in various business environments such as banking, healthcare, and office automation. However, the technology has not yet been fully investigated for its potentials as a model of CPD. Previous major projects and initiatives such as MADEFAST and CyberCut in computer supported CPD did not address the issue of workflow or use the workflow technology to facilitate the collaboration. Nevertheless, several attempts have been made in the field of product design and manufacture [4]. Another notable recent development in this direction is the recognition of the issue in the TEAM (Technologies Enabling Agile Manufacturing) program which is one of the major projects that make extensive uses of the Internet and Web technologies. However, these models have not yet been implemented according to a recent newsletter. Let us now move on to the second research question: why and how the Web technology complements the WFM technology. It has long been recognised that Web-based user interfaces were not a novelty but a necessity for WFM systems to compete in the marketplace. Indeed, the Web technology has been employed in developing WFM systems. Miller et al. [14] cited a number of Web-based or Web-enabled WFM systems. Their work on WebWork highlights several advantages of the Web-based WFM such as the ease of development of workflow applications, installation and use. These have also been the main reasons why the authors and other researchers have chosen the Web technology to develop TeleDSS in the field of product design and manufacture. If such TeleDSS are to be co-ordinated, the Web technology is a natural choice. The need for incorporating the WFM technology into the Web-based CPD can be discussed from several aspects. First, the Web browser suffers from limitations in its present form. For example, the Web browser is poor in supporting WFM required in CPD. At present, browsers provide rudimentary navigating facilities, going backward or forwards or jumping to specific Web pages. The flow of these Web pages does not reflect the flow of the work involved in the project. Even worse, Web pages have hyperlinks. After a few moves, if the Web pages of application systems are not carefully designed, then the user is easily lost without knowing where he or she comes from and which pages he or she should go next. Readers may have experienced such frustrations in surfing on the Web. In addition, the Web browser does not provide sufficient supports for decision traceability, especially when multiple TeleDSS are employed in a project. Let us assume a simplistic situation where two TeleDSS are involved. After the first TeleDSS finishes its task, the second system is activated in the Web browser. Some of the input data to this second system may come from the output results from the first

140

G.Q. Huang et al. / Computer-Aided Design 32 (2000) 133–144

system. The previous Web page for the first system may have lost its data before they are required by the second system. This makes it difficult for the user to use the second system. This is particularly serious if the two systems are activated in two different sessions on different days. Finally, different TeleDSS are developed and provided by disparate third parties, and consequently, do not usually share a common working memory. Instead, they use their own private working memories for input/output and intermediate results from problem solving. Such working memories may reside in the servers where the TeleDSS are deployed, or may reside in the clients, depending on their original designs. When multiple TeleDSS are assigned for the single project, it becomes necessary for them to share a common working memory. 4.2. Workflow management model In order to address the above issues, a new Web-based WFM framework is proposed for planning and controlling the flow of work, data and control, and executing any part of the workflow from any location. Data transactions and document routing are usually described as main functions of workflow technologies. In the field of CPD, the WFM is mainly concerned with the co-ordination of remote TeleDSS on the World Wide Web. Several features are incorporated. First, the project network model is adopted as the workflow model. The nodes represent project work packages or simply work. Edges represent the logical relationships between work (packages), i.e. the flows of control and data. As a result, the WFM system is also a project management system for the distributed CPD team. Initially, agents are logically configured into a project network. This initial network will act as a guide during collaborative work to determine when a TeleDSS is activated or terminated, whether several TeleDSS can perform their activities simultaneously or sequentially, etc. Second, the proposed system builds on the concept of agents proposed in the preceding section. An agent represents the work package, its supporting TeleDSS, and its responsible human user(s) in the workflow. If all the agents involved in a project workflow share the same agentBoard, then agentBoard becomes a common working memory. Its functionality is similar to that of blackboard metaphor widely used in distributed problem solving. agentBoard ensures the traceability of the decisions at different stages by recording them in a decision tree in terms of the contents of the decisions, the decision-makers, and precedence decisions, etc. agentBoard also enables agents to exchange their input and output data. In addition, there are not direct interactions between TeleDSS. All interactions are delegated to their agents. Agents are only one of the two main constructs in the workflow network model. That is, agents are only used to define the work (packages) as nodes of the network model of project workflow. Relationships between nodes are

separately defined in terms of flows. Without flow definitions, agents still do not know where inputs are obtained from and outputs are sent to. The separation of flow definition from work definition provides opportunities to reuse agents for for different projects once they are defined for TeleDSS. No further changes are necessary when agents are used for other projects. What the project team needs to do is to choose the agents according to the work packages of the project and define the flows of control and data between agents to suit specific requirements. Finally, this agent-based WFM model is able to support both the co-located and distributed teams. This is because an agent can be activated anywhere on the Web as long as an authority such as a key or password is given. If the team is co-located, then only one Web browser is used to download the workflow navigator. All the agents can be activated from this navigator client using the appropriate keys or passwords. If the team is distributed, several navigator clients are created at different locations. One or more agents may be activated at one location using the appropriate key or password(s). In terms of implementation, the Web-based WFM system, wfManager, has two components. One is the client-side component, wfNavigator, and the other is the server-side component, wfEngine. They are deployed either at the same Web server or at two physically different Web servers. The workflow engine, wfEngine, is the server-side component. It is executed and always remains at the server machine. As shown in Fig. 3, several wfNavigator clients share the same wfEngine server. The server-side component of the wfNavigator is responsible for data management with the database server. Both components operate in two modes to support workflow definition and execution. In the editing mode, wfEngine is mainly responsible for dealing with details of the workflow definition. In the executing mode, wfEngine is mainly responsible for notifying all the changes to wfNavigator clients. It is important to note that wfEngine is NOT responsible for saving changes of agent properties in agentBoard. This is accomplished by the agentEngine which is another separate remote service. 4.3. Workflow definition Workflow management involves two general stages, i.e. workflow definition and execution. Accordingly, the user interface of wfNavigator must have two working modes. One is the editing mode where the team defines the agentbased workflow for a specific product development project. The other is the executing mode where the team monitors and controls the progress of executing a project workflow. Workflow definition in turn involves the “work” definition and the “flow” definition. A product development project consists of a number of work packages or activities. Each work is defined by an agent. This agent can be selected from pre-defined agents

G.Q. Huang et al. / Computer-Aided Design 32 (2000) 133–144

141

Fig. 3. Agent-based workflow management model.

in the agentBase. Alternatively, a new agent may be defined for this specific work package using agent definition facilities incorporated in wfNavigator. AgentEngine is contacted to manage the definition details of agent templates. Two types of flow are identified in Fig. 4. They are flow of control and flow of data. The flow of control between work agents defines their dependencies. For example, Agents 2 and 3 can only start their work after Agent 1 completes its work. Agents 2 and 3 may work simultaneously. The flow of data refers to the situation where agents share their property data. Some outputs from an agent may be the inputs to other agents. Such relationships can be easily defined in a similar way that relationships are defined between data tables in a relational database. For example, Agent 2 takes its input data from its human user and output properties 1 and 2 of Agent 1, respectively. Agent 3 takes its input data from output properties 2 and 3 of Agent 1 and its human user, respectively. Flows of data can be compared to messages widely used in MAS for communication.

Flows of data, or message passing, are triggered by the flow of control. For example, if Agent 1 has not finished with its work, flows of data associated with Agents 2 and 3 will not be processed. The general procedure of defining a project workflow is as follows: • The team members use Web browsers to connect to the Web server where wfNavigator is deployed; • WfNavigator is then automatically downloaded to and manually activated at the corresponding client machines; • AgentEngine may be contacted to retrieve previous agent definitions from the agentBase; • Work packages are identified for the project and agents are defined in wfNavigator; • AgentEngine is contacted to save details of agent definitions in agentBase if any new agents are created; • Flows of control and data are then identified and defined in WfNavigator; and • WfEngine is contacted to save details of the workflow definition in wfBase.

142

G.Q. Huang et al. / Computer-Aided Design 32 (2000) 133–144

4.4. Workflow execution Once the workflow is fully defined, it can be executed. The user or user team can simply follow the logic and execute the project. The project manager as a user can have a clear overview of the progress of a product development project. Team members can use this facility to check if the conditions of their work packages are met so that they can be started. The general procedure of executing a workflow is as follows: • The team members use Web browsers to connect to the Web server where wfNavigator is deployed; • WfNavigator is then automatically downloaded to and manually activated at the corresponding client machines; • WfEngine is contacted to retrieve the workflow model defined in advance; • The first agent in the workflow is activated. The agent is executed according to the procedure discussed in the preceding section. Its incoming messages defined as flows of data associated are fired. Therefore, this agent knows from where its input data come; • After preparing its input data, agentEngine is contacted to save the input/output and other data to the agentBoard; • The agent connects and submits its input properties to its corresponding TeleDSS, if any; • TeleDSS is activated to produce and return the output data to the agent to update its output and control properties; • AgentEngine is contacted to save the changes in agent properties;

• WfEngine notifies all wfNavigator clients about the changes; • The user is prompted if the output is accepted or a backtracking is necessary; • Upon completion, the control is passed over to subsequent agents. Each of them may have to be executed by another team member at a different location as a separate client; and • This process repeats until the last agent in the workflow is completed.

5. Concluding discussions This paper has described a Web-based framework for CPD. The framework integrates the concept of agents into WFM. The workflow of a product development project is represented in the network model. Network nodes represent work packages while edges represent the logical flow of work, i.e. flow of control and data. These familiar notations widely used in conventional project management are adopted in the workflow model so that user can learn them easily and quickly with minimum overheads. Furthermore, new constructs are introduced to deal with the situation where Web-based decision support systems (TeleDSS) are extensively used in product development process. A new agent model is proposed. Agents add a sandwich layer between the human users and remote services. Each agent is assumed to be responsible for one work package/activity of the project. Agents prepare input data, call the remote

Fig. 4. Two types of flow of work: control flow and data flow.

G.Q. Huang et al. / Computer-Aided Design 32 (2000) 133–144

services, and then collect output data. All these data are captured as agent properties that are in turn recorded in a central database. This database provides opportunities for the users to trace back previous decisions and for agents to share data during collaborative process. One important contribution is the integration of the agent concept into WFM. Initially, agents are configured into a network model according to the dependency relationships between the work packages/activities. Such flows of control between agents are used to trigger the messages defined as flows of data between agents. It is through these messages that agents share their properties to collaborate. The separation of work from flow is a unique feature of our proposed agent-based WFM framework in contrast with most multi-agent systems. One of the most significant advantages of separation is that agents can be defined for specific remote services on the Web but independent of specific projects. Same agents may be reused in the workflow of different projects without any changes. It is necessary to define only the flows between them. Having highlighted its major advantages, our proposed framework has its own limitations. At this moment, agents are used to define work packages that may be further decomposed into lower-level tasks and activities. These would form internal workflow within individual remote services. Such intra-agent workflow is not considered at present. Instead, only inter-agent workflow is included. Another major issue is dependencies between agents, i.e. flows of control and data. There are static dependencies specifying predecessors and successors, and there are dependencies that are dynamically generated during the course of decision-making. At present, only predefined static dependencies are included and dynamic dependencies may be investigated as follow-up activities of this project in the future. Future work would focus on developing an initial prototype system that fully demonstrates the ideas. Implementation considerations have been taken when proposing the methodological framework. Most of the ideas are in fact based on our past experience in developing Web-based applications in CPD. In the medium terms, illustrative case studies must be implemented to demonstrate the working process. Strengths and weaknesses would be identified for further refinement of the methodology and the system. In the longer terms, investigations should be carried out into the possibilities of extending the agent model into a general-purpose client development environment.

Acknowledgements The authors are grateful to the two anonymous referees for the critical but constructive comments on the original

143

manuscript. The authors are also grateful to the Hong Kong Research Grants Council (Project HKU 7230/99E) and the Committee on Research and Conference Grants of Hong Kong University for providing the financial supports for this work. We would like to acknowledge the discussion with Professor H. Meerkamm and Mr C. Mogge under the Germany/Hong Kong Joint Research Scheme.

References [1] AIMS, http://aims.parl.com/ [2] Anton AI, Liang E. A Web-based requirement analysis tool. In: Proceedings of WET ICE’96, 1996, p. 238–43. [3] Bailey MJ. Tele-manufacturing: rapid prototyping on the Internet. IEEE Computer Graphics and Applications 1995;November:20–26. [4] Brockman JB, Director SW. The schema-based approach to workflow management. IEEE Transactions on Computer Aided Design of Circuits and Systems 1995;14(10):1257–67. [5] Cutkosky MR, Tenenbaum JM, Glicksman J. MADEFAST: collaborative engineering over the Internet. Communications of the ACM 1996;39(9):78–87. [6] Erkes JW, Kenny KB, Lewis JW. Implementing shared manufacturing services on the world wide Web. Communications of the ACM 1996;39(2):34–45. [7] Faulkner PD. Statistical process control of test results via the Internet. In: Proceedings of National Electronic Packaging and Production Conference, 1997, p. 1159–65. [8] Fukuda S, Jiang PY. An infrastructure to support closed loop product development practice coupled with rapid prototyping DETC98/EIM5685, 1998. [9] GEN, http://urobe.uni-paderborn.de/GEN/ [10] Huang GQ, Mak KL. Web-based collaborative product development. Invited lecture, 1st International Seminar and Workshop on Engineering Design in Integrated Product Development, Wroclaw, Poland, 8– 10 October 1998a. [11] Hague, Taleb-Bendiab. Tool for the management of concurrent conceptual engineering design. Concurrent Engineering: Research and Applications 1997;6(2):111–29. [12] KQML, http://www.cs.umbc.edu/kqml/ [13] Krause FL. Global product data management. In: Proceedings of 2nd International Conference on Concurrent Engineering: Methods and Tools, 1998. [14] Miller JA, Palaniswami D, Sheth AP, Kochut KJ, Singh H. WebWork: METEOR2’s Web-based workflow management system. Journal of Intelligent Information Systems 1997;10:185–215. [15] Minis I et al. OSPAM: Optimal selection of partners in agile manufacturing, http://www.isr.umd.edu/Labs/CIM/ospam/short.html, 1995. [16] Muller PC, de Poorter R, de Jong J, van Engelen JML. Using the Internet as a communication infrastructure for lead user involvement in the new product development process. In: Proceedings of WET ICE’96, 1996, p. 220–25. [17] O’Leary DE, Kuokka D, Plant R. Artificial intelligence and virtual organisations. Communications of ACM 1997;40(1):52–59. [18] Petrie CJ. Agent-based engineering, the Web, and intelligence. IEEE Expert 1996;December:24–29. [19] PRODNET, http://www.uninova.pt/~prodnet/ [20] RaDEO Program Home Page, http://radeo.nist.gov/radeo/ [21] Romano NC, Nunamaker JF, Briggs RO, Vogel DR. Architecture, design, and development of an HTML/JavaScript Web-based group support system. Journal of the American Society of Information Science 1998;49(7):649–67. [22] Roy U, Bharadwaj B, Kodkani SS, Carian M. Product development in

144

[23]

[24] [25] [26] [28] [30] [31] [32]

G.Q. Huang et al. / Computer-Aided Design 32 (2000) 133–144 a collaborative design environment. Concurrent Engineering: Research and Applications 1997;5(4):347–65. Smith CS, Wright PK. CyberCut: a world wide Web based design to fabrication tool. Journal of Manufacturing Systems 1996;15(6):432– 42. Sriram D, Logcher R, Fukuda S, editors. Computer aided cooperative product development Berlin: Springer, 1989. TEAM, http://cewww.eng.ornl.gov/team/home.html Wagner R, Castanotto G, Goldberg K. SPIE 1995;2596:192–5. van Leeuewn F. Relating groupware and workflow. In: Lawrence P, editor. Workflow handbook, New York: Wiley, 1977, p. 75–88. http://wim.isx.com http://dayton.ca.sandia.gov/pre/ Orfali R, Harkey D. Client/server programming with Java and CORBA. 2. New York: Wiley, 1998.

Dr G.Q. Huang gained his BEng and PhD in Mechanical Engineering from Southeast University (China) and the University of Wales Cardiff (UK), respectively. He is an Assistant Professor in Design and Manufacture at the University of Hong Kong. He is recently involved in developing Web-based design tools for collaborative product development on the Internet/ Intranet.

Professor K.L. Mak is Professor and Head of Department of Industrial and Manufacturing Systems Engineering, the University of Hong Kong. He obtained both his MSc (Engng) degree in Manufacturing Engineering and PhD degree in Systems Engineering at the University of Salford in England. He is a Chartered Engineer, and had wide exposure to industry prior to joining the University of Hong Kong. He worked in some UK engineering enterprises, including the Pilkington Brothers Ltd. the T.S. Harrison and Sons Ltd. and some enterprises in Hong Kong. Professor Mak’s current research interest focuses mainly on Production and Operations Management, Manufacturing Systems Design and Control, and Product Development, and has published extensively in these areas.

Jin Huang is now a Research Associate in the Department of Computer Science at the University of North Carolina at Charlotte. Dr Huang received his BEng, MS, and PhD in Industrial and Manufacturing Systems Engineering from Xi’an Jiao Tong Universityin 1991, 1994, and 1997, respectively. Prior to his present appointment, he worked at the University of Hong Kong and at Shanghai Jiao Tong University as a Research Associate. He has recently participated in the EECOMS project funded by the NIST and the IBM Corporation. He also directed projects funded by NSFC, National Hi-tech Foundation of China, and Shanghai Automotive Industrial Company. His research and works interests are in the areas of computer-supported cooperative work, enterprise integration, enterprise resource planning, supply chain management, agent technologies, and object-oriented software construction.