a concurrent engineering meeting environment for virtual design teams

Arti®cial Intelligence in Engineering 14 (2000) 203±219

www.elsevier.com/locate/aieng

CAIRO: a concurrent engineering meeting environment for virtual design teams F. PenÄa-Mora a, K. Hussein b, S. Vadhavkar c,*, K. Benjamin d a

Department of Civil and Environmental Engineering, Room 1-253, Massachusetts Institute of Technology, Cambridge, MA 02139, USA b Riskclick.com, New York, NY 10016, USA c Intelligent Engineering Systems Laboratory, Department of Civil and Environmental Engineering, Massachusetts Institute of Technology, Cambridge, MA 02139, USA d Oracle Exchange, Oracle Corporation, Redwood Shores, CA 94065, USA

Abstract This paper presents the software architecture for a next generation concurrent engineering environment that helps geographically separated designers and engineers to collaborate effectively. The paper highlights research in computer-supported collaboration work (CSCW) based on various models of group interaction, social communication theory, negotiation theory and distributed arti®cial intelligence concepts. The paper describes CAIRO (Collaborative Agent Interaction and synchROnization) system, a distributed conferencing architecture for managing designers and engineers in a distributed design meeting. The CAIRO system allows designers and engineers to work together in virtual teams by supporting multi-media interactions over computer networks. CAIRO aids the concurrent engineering effort by relaxing the physical, temporal and organizational constraints experienced in traditional design meeting environments. CAIRO provides both media synchronization, i.e. ensuring that all information exchanged between users is synchronized, and agent synchronization, i.e. ensuring effective structuring and control of a distributed conference. This paper also details the prototype CAIRO system with a detailed example, illustrating its use in concurrent design settings. q 2000 Published by Elsevier Science Ltd. Keywords: Collaboration model; Concurrent engineering; Conference management; Meeting environment; Virtual teams

1. Outline The following statement from Peter Senge, Director of the Center for Organizational Learning at MIT's Sloan School of Management, summarizes the importance of teams in modern organizations [1]. ¼teams, not individuals, are the fundamental learning unit in modern organizations¼unless teams can learn, the organization cannot learn. Today, structural design is more complex than ever before. It is beyond the scope of a single person, a single team or even a department to comprehend fully all the aspects of the design effort. Availability and communication of expertise remain the key factors in the success of * Corresponding author. MIT, Room 1-270, 77 Massachusetts Avenue, Cambridge, MA 02139, USA. Tel.: 11-617-253-6232; fax: 11-617-2536324. E-mail addresses: [email protected] (F. PenÄa-Mora), [email protected] (K. Hussein), [email protected] (S. Vadhavkar), [email protected] (K. Benjamin). 0954-1810/00/$ - see front matter q 2000 Published by Elsevier Science Ltd. PII: S 0954-181 0(00)00016-9

modern organizations. The problem is compounded in the architecture/engineering/construction (A/E/C) industry, marked with growing sizes and geographic dispersion of large-scale projects. It has been a challenge for the designers and engineers in traditional organizations to work together as teams to improve the quality, while reducing costs and time in the design process. Enter concurrent engineering (CE) Ð a systematic approach to integrated development that embodies the team values of cooperation to share decision-making. To identify the role of CE and document our research in distributed design environments, this paper is divided into ®ve sections. The primary principles of CE are highlighted in Section 2. This section also identi®es the importance of supporting distributed design teams with comprehensive computer environments. Section 3 describes the system design of the software architecture developed by the authors to create a CE environment. Section 4 provides an illustrative example depicting structural design carried out by a team of geographically distributed designers over the computer network. Finally, concluding remarks are provided in Section 5.

204

F. PenÄa-Mora et al. / Arti®cial Intelligence in Engineering 14 (2000) 203±219

include computer networks, hardware and software required to make geographically separated teams to work together. From the time perspective, CE has the goal of reducing the length of the product cycle time. Amongst the above-mentioned in¯uencing agents, cooperative work teams remain the single most important component of CE [6,7]. This is primarily because the òrganizational angle' of CE involves many constantly changing variables that are more dif®cult to control than any other variable. There are four primary elements to cooperative work teams:

Fig. 1. 7T's Ð seven in¯uencing agents of concurrent engineering (from Ref. [6]).

2. Concurrent engineering and teams The concept of CE was initially proposed as a means to minimize product development time [2,3]. Since then, many de®nitions of CE have emerged in literature: ² Concurrent Engineering is a `systematic approach to the integrated, concurrent design of products and their related processes.' This approach is intended to cause the developers, from the outset, to consider all elements of the product life cycle from conception through disposal [2]. ² Concurrent Engineering is a `goal-directed effort, where ownership is assigned mutually among the entire group on the total job to be completed, not just pieces of it, with the understanding that the team is empowered to make major design decisions along the way.' This de®nition is more suited to a virtual CE enterprise with geographically separated designers as it highlights the importance of distributed teams [4]. The above de®nitions indicate that most of the basic principles of CE, revolve around the notions of teamwork af®nity and shared knowledge leveraging. Indeed, CE strives to create teams of people working together to create global optima in their efforts [5]. Individuals, working remotely in separate locations are likely to create designs, which may be optimal in their individual local domains but will seldom remain optimal in a uni®ed domain. The core components of any CE effort are highlighted next. As shown in Fig. 1, Prasad has identi®ed seven agents that in¯uence the domain of CE: talents, tasks, teams, techniques, technology, time and tool [6]. One of the primary team issues in CE is the decomposition of tasks. Teams are often used to cooperatively solve the problem. Technology issues arise in CE due to drive for competitiveness. Tools

² Communication involves the exchange of information, events and activities in any CE effort. Effective communication is a necessary, though not a suf®cient condition to meaningful collaboration. ² Co-location involves dealing with the infrastructure to provide seamless communication among distributed designers and engineers. ² Coordination involves control of the work¯ow and communication process, allowing ef®cient control mechanisms to coordinate group effort. Coordination involves managing the various interdependencies between activities and events in any CE effort. ² Collaboration describes the process of sustainable value creation that creates a shared understanding in the CE effort. Communication has always been a well-known threat as well as an opportunity in large-scale complex projects [8]. Costly breakdowns in communications occur regularly even in the traditional A/E/C projects of physically collocated teams that are engaged in design and construction [9]. In the engineering domain, communication is an integral component of the design and problem-solving processes. Systems that are currently developed contain large numbers of components and encompass the knowledge of thousands of person-years. Clearly, this is much more than one individual can retain in their limited mental storage capacity. Hence, the modern engineering process necessitates the engagement of several individuals in the realization of an artifact or product. Engineering meeting processes particularly highlight several issues in communication: representation Ð different standard terminology and acronyms; transportation Ð in the form of symbolic drawing, sketches, speci®cations and associated multi-media; organization and control Ð inter-linkages of system components and the need for diverse expertise in problem-solving, beyond the capacity of one individual [10]. Design teams provide a signi®cant challenge to current communication technologies. Design processes require highly coordinated interaction to resolve design disputes and to align design goals within the team [11]. In addition engineering design also typically involves ill-de®ned design problems that are composed of interrelated components designed by different individuals that must work in tandem


to produce a system/artifact. This adds another dimension of complexity to the coordination task, since access to the design artifact must be coordinated in order to avoid design failures. Finally, most engineering design requires multimedia interaction for product visualization and system development. Few design teams in modern A/E/C projects enjoy the bene®t of physical collocation (same room-same time). The balance has moved signi®cantly away from design activities requiring physical collocated functions to those ones relying on distributed expertise with dynamic decision-making capabilities. The current approach is more towards virtual teams that collaborate across geographical, temporal, cultural and organizational boundaries to achieve global maxima in design. Design teams therefore increasingly need to make extraordinary efforts to establish and maintain a sense of communication, co-location, coordination and collaboration. Software tools and hardware solutions that support such distributed design teams have therefore become a necessity rather than a fad. Commercially available audio and videoconferencing services are increasingly becoming popular in design of®ces. Studies reported from the A/E/C and other industries indicate that the use of such tools and technologies in CE have resulted in direct savings in project life cycle and costs [12±14]. In addition, such CE environments directly contribute value to team efforts. Indeed, reliable communication, ¯exible access and retrieval of information, timely connectivity with global experts, all translate to the success of a team project. These CE environments are often grouped together as computer-mediated communication and collaboration tools. Concurrent engineering environments for engineering design therefore require enabling methods and techniques that can ensure the interoperability of building product models and the data exchange and sharing with various heterogeneous applications, taking into account the distributed, multidiscipline nature of construction projects [15]. There has been a signi®cant amount of research in the area of computer-mediated communication and collaboration. Prior research has addressed traditional problems such as resource-allocation, optimized design process management using arti®cial intelligence techniques such as neural networks, knowledge-based expert systems and genetic algorithms [16±19]. The work spans multiple disciplines and hence there are three diverse focus areas in this research ®eld: Electronic Meeting Systems (EMS); Video Conferencing; and Shared Social Spaces [20]. Each of these groups represents a different approach to computer-mediated communication. EMS research focuses on the meeting process and decision support tools for the meeting process. Video conferencing research is concerned with transmitting multi-media data between participants (especially audio and video data). The shared social spaces perspective is concerned with enabling interaction and experience across distance providing awareness and persistence within a virtual world. Some of the current computer mediated

205

communication systems (both academic and commercial) are surveyed in detail in Refs. [21,22]. To address some of the missing pieces from contemporary systems, the authors have developed CAIRO [20,22±25]. The CAIRO (Collaborative Agent Interaction and synchROnization) system is a distributed CE environment that allows designers and engineers to interact over a computer network, without the physical and temporal constraints experienced in traditional meetings. The next section highlights the top-level system architecture of CAIRO. 3. System architecture CAIRO system provides an environment for structured information exchange across the Internet in real-time. This section presents the design of CAIRO collaboration architecture to support distributed collaborative meetings. Before going into the system architecture details, the general requirements [25] for a CE environment are summarized here. 1. Multiple media channels are required since group communication is generally comprised of audio and visual data. 2. Multimedia channel synchronization is essential due to random delays inherent in the underlying network. 3. A conference control mechanism is required to provide ef®cient group interaction and design negotiations. 4. The system must be adaptable to different conference styles (from informal, unstructured conversation to a stringent and formal conversation control mechanism). 5. The system must support groups in the various stages of formation, i.e. the ability to have hierarchically structured groups that are easily expandable. The CAIRO system is comprised of several interlinked modules and servers (see Fig. 2). Each participant engaged in a CAIRO conference spawns a Collaboration Manager (shown as a dashed box), which is comprised of media drivers (shown as pictograms of the media, for example, video camera and microphone) and message servers (indicated by the acronym `MSG'). The message servers package data for transmission over the network and enforce synchronization constraints during media playback. Forum servers are processes that maintain control of a conference among several individuals and enforce membership constraints. Furthermore, forum servers log all conference proceedings. Forum managers (not shown) spawn forum servers, which de®ne a speci®c control methodology. Forum managers also provide mechanisms for converting a forum server's control strategy. Finally, the name server maintains a directory of all participants, forum managers and forum servers within the CAIRO system. Further details of the architecture can be found in Refs. [20,22±25]. Critical design elements of the CAIRO system are:

206


Fig. 2. CAIRO module diagram.

synchronous communication support, coordinated interaction support, system modularity and extensibility with a variety of media and tools, robust and reliable communication, and a multi-user interface for collaboration. CAIRO establishes a system in which its users or clients, each with access to the Internet and to the CAIRO software, can meet in a virtual meeting environment. The entire system operates under the object model described in Fig. 3 [25]. The system architecture is presented in Fig. 4. 3.1. Client/forum When an engineer/designer (user) wishes to use the system, s/he must start up the CAIRO client and register with the nameserver, which itself is a Java message sending program running on some computer connected to the Internet. Once a user has registered with the nameserver, the nameserver provides the CAIRO client with a list of all the meetings that are currently running on the CAIRO system. A meeting, or forum as it is named in the CAIRO

system, is another Java message sending program. Once a user decides to enter a forum, messages are then passed directly from the CAIRO client to the particular forum. A forum is a virtual presentation of a meeting room where users can collocate over the Internet. CAIRO provides communication tools to engineers/designers that are more conductive to the engineering collaboration process. In addition, CAIRO embodies the notion of a meeting control strategy, including chaired meetings, roundtable meetings, and lecture meetings [25,26]. 3.2. Meeting control strategies In a chat room anyone can make a comment or talk at any point in time. However, actual engineering negotiation meetings cannot follow this format for it would lead to chaos. The CAIRO system allows forums to take on characteristics similar to those of actual meetings, which are called meeting control strategies. A strategy is a way of deciding which member of a meeting is allowed to contribute to the

Fig. 3. CAIRO object model diagram.


207

Fig. 4. CAIRO system architecture.

meeting. An example of a control ¯ow strategy is one that models a chaired meeting. In the chaired meeting strategy, one client is designated as the chairperson of the meeting. If another client wishes to collaborate with other clients in the meeting, s/he must ®rst request permission from chairperson. Another example is a roundtable control strategy. As may be inferred, any client can collaborate at any point in time for there is no chairperson, and permission need not be requested. There are several other control processes under development in the CAIRO system as described below. 3.3. Chairman meeting The chairman meeting control strategy is analogous to a real world board meeting. In such a meeting, a designated chairman is in control of all aspects of the meeting. Most importantly, the chairman controls who gets to communicate with other members of the meeting and when. If the chairman wants to address everyone in meeting s/he simply takes the ¯oor and communicates as she/he pleases. S/he does not require anyone's permission to communicate. However, if another member of the meeting wishes to address others in a meeting, s/he will most likely to raise his/her hand and get permission of the chairman to talk. If the chairman thinks that the meeting member should talk, then the request is granted or otherwise denied. In the chairman meeting control strategy for CAIRO, similar control has been implemented. Because you really can't raise

your hand on a computer, CAIRO has implemented popup menus so that users can request a variety of things including talking to everyone, talking to particular individuals, and the means for accepting and denying requests. 3.4. Free style meeting The free style meeting control strategy is analogous to a very informal meeting. In such meetings, no particular person is in charge. Here, meeting members can take the ¯oor and communicate with other members as they please, allowing all users to contribute to the collaboration process equally. Ideas can be expressed freely without censorship. Essentially, there are no accept and deny request protocols. 3.5. Lecture meeting The lecture meeting control strategy is analogous to a real world lecture or classroom setting. Similar to the chairman control, the lecturer controls all communication in the meeting. Requests are done in the same manner with menus, and all necessary requests go to the lecturer. Fig. 5 shows the user interfaces for all three meeting control strategies. The CAIRO system employs the real world metaphor for its user interface. Here, the conferencing user interface presents the user with a 3-dimensional environment. This is done to make the user feel more comfortable with the CAIRO system and ultimately aid in the productivity of the collaboration process through the CAIRO system [26].

208


Fig. 5. Control interfaces: roundtable, chairman, lecture.

These meeting control strategies are one of the most important contribution of the CAIRO system to the distributed collaboration process [25]. There are other Internetbased conferencing systems currently available that allow for communication. However, all of them concentrate on the application-to-application side of collaboration and are not speci®cally geared to handle people-to-people collaboration [22]. By implementing ways of controlling which users communicate when and who is able to grant permission to communicate, the CAIRO system introduces a new level of control and structure to Internet conferencing which better facilitates the distributed collaboration process. 3.6. Side conversations A ®nal component of the control mechanism embodied in the CAIRO system is the concept of side conversations. Members of face-to-face meetings often feel it necessary to lean over the next person, and whisper something, or comment on what is currently being discussed. Since they may not want to share this information with everyone, the ability to have side chats is important. One of the pop-up menu options in the CAIRO system includes a Side-Chat option. Here, a member of the meeting can request a side conversation with another member of the meeting. The request is made known only to the members involved, regardless of the current meeting control strategy and/or the presence of a chairperson. If the other member chooses to accept the side conversation, both members are moved to a similar side conversation virtual room. CAIRO implements a tab metaphor to manage side conversations. Each new side conversation creates a new tab on the user

interface. Fig. 6 provides an example of a side conversation in progress. Members of a side conversation can communicate with each other freely. For this reason, the new tabs are also created on all collaboration tools to allow side conversation users not to be limited in how they communicate. There are two important aspects of the side conversation. The ®rst is that those members that are not involved in a side conversation have no knowledge about the side conversation and the members involved in that side conversation. The other important aspect is that the members not involved in a side conversation are not privy to the information being exchanged in the side conversation. In Fig. 6, the user interface on the left shows a room with three members present at a meeting. The tab indicates that the user is in the main meeting room. The interface on the right shows a user in a side conversation. There are only two members located in the virtual room, which is indicated by the tab. The privacy issues encoded into the CAIRO system follow along the whispering metaphor of side conversations, common in typical design meetings. 3.7. Agendas Associated with the CAIRO concepts of clients and forums is the notion of a meeting agenda. An agenda is de®ned in Webster's Dictionary as à list, outline, or plan of things to be done.' An agenda presents a list of things to be done during the course of a meeting, and it should specify a notion of how long each activity should take. In the CAIRO system, an agenda works in conjunction with a forum to conduct a meeting, much like a real world, faceto-face meeting. Within the de®nition of an agenda, each


209

Fig. 6. Meeting with side conversations.

item has an associated time and an associated control ¯ow strategy. In CAIRO, once a forum object has been started with a certain agenda, a collaborative meeting can be initiated. As each agenda item is tackled, a certain control ¯ow strategy is employed which is hopefully conducive to the productivity and on-time completion of the particular agenda item. 3.8. Software agents The major component of the CAIRO system is the set of distributed arti®cial intelligence based software agents. An agent can be generalized as a software component or program that works in conjunction with people or represents people and acts in their best interests. It is almost impossible to run a fair meeting when you have a personal investment in the subject matter [27]. The agent removes some level of direct involvement in running a meeting. Therefore, abstracting and encoding the running of an agenda for meetings through an agent helps accomplish the ultimate goal of productive meetings. The goal of the software agents in CAIRO is to learn to work along with the user to make the meetings as effective as possible. A number of software agents have been developed in the CAIRO system. The general requirements and the function for each of them are explained in detail in the next couple of paragraphs. The meeting control process should help dissipate con¯ict elements among the participants during an engineering design negotiation. Professional facilitators are often employed to invoke meeting process changes to ensure the focus of the design group and to reduce con¯icts in the meetings. Characteristics of effective facilitators are

identi®ed in Ref. [28] and are enumerated below: 1. 2. 3. 4. 5. 6.

Neutrality Process expert Maintains issue focus Information resource Trustworthy, non-authoritative Not a decision-maker

In CAIRO, some of these requirements are satis®ed through the use of computerized facilitator agents [25]. These agents reduce the overhead required in the facilitation of change negotiation. The agents are, 1. Inherently neutral, since they are computer-based and have no emotions or hidden agendas; 2. Encoded with various process intervention heuristics and their reaction evolves with the use of the system; 3. Trustworthy, since they acquire the trust of the user by informing the user of all the agent's decisions and allowing the user to adjust control parameters as they evolve. In relation to the agenda, one of the software agent tracks the agenda for the user. During a CAIRO meeting, if the time associated with an agenda item should expire according to the set agenda, then the agent will make a suggestion to the meeting chairman to move on to the next agenda item with the item's speci®ed control ¯ow strategy. The client may choose to follow the agent's suggestion. If so, the agent will make note of the current meeting situation and observe the user's tendencies. However, a client may also reject the agents suggestion. In this situation, the agent would modify

210


Fig. 7. CAIRO agent on meeting minutes.

its assumptions of the user's tendencies, and these new assumptions would be re¯ected in future suggestions [25]. Fig. 7 shows an example of one of the agents implemented in the CAIRO architecture. This particular agent tracks the meeting minutes as per the agenda that has been setup, and warns the chairman of the meeting in the event that the agenda is being disrupted. Agents in CAIRO also monitor the collaboration activity during meetings. Agents monitor the content of text messages being delivered among the members of the meeting, parsing the information, looking for key words. If the agent ®nds words such as èxplain', then the agent would suggest that the members of the meeting change to a lecture meeting control strategy. Another example would be if the agent ®nds the word `discuss', then it would make the suggestion to move to a roundtable meeting control strategy. All this parsing information is kept in a dictionary ®le, which can be edited by the CAIRO users. In addition to monitoring the content of meeting communications, agents also monitor the communication requests. If, during a chairman meeting control strategy, the agent notices that there is an unusually high number of requests to talk, then the agent may suggest to move to a roundtable meeting control strategy. The roundtable meeting control strategy facilitates the communication need for many meeting members. The facilitator agents are coupled to the control mechanisms. The agents establish the appropriate control mechanism for a given meeting setting. The choice of conference control strategy at appropriate meeting milestones is critical in the effective coordination of group effort. The agent architecture developed in CAIRO is intended to automatically determine the strategy relevant to the current topic of discussion. The basis of the agents decision is an encoded meeting agenda as well as the meeting indices [25,26]. Although the agenda and process representations are linear, typical design discussions involve a cyclical re®ning process. Hence, the agent must be able to traverse the agenda in accordance with the discussion patterns.

The mapping of process and agenda stage to appropriate facilitation strategy are currently very simple and are based on several heuristics. The critical issue is the agent's responsibility to determine the transition between the stages outlined in the agenda and process model. The agent bases its behavior on the conversation graph and its relation to the design process and expressed agenda. The facilitator agent builds a rapport with the conferring individual through an interface technique that builds trust between user and agent as proposed in Ref. [29]. Initially, the agent is encoded with very basic heuristics and will not make any independent decisions. The agent has a caricature representation that informs the user of its current process state (thinking, suggesting, grati®ed, disappointed, or confused). As decision points arise, the agent would make suggestions and show expressions of sadness or happiness dependent upon the reaction of the human user. As the agent suggests process interventions, the user may either reject or accept them. Eventually the agent builds thresholds for decisions that may be taken without user intervention. This interactive agent scheme ensures that a trusting relationship is built between agent and user. Each agent has access to information regarding the user as well as the design process. This includes an encoding of user preferences for agent autonomy (i.e. an indication of what decisions the user is willing to delegate to the agent). The agent decisions on process interventions are based on the following aspects of the agent environment: 1. The current topic's recommendation list. 2. Threshold levels indicating user preferences. 3. An averaged record of the participation of each participant in the design process. 4. The complete conversation model of the ongoing negotiation. It is important to note that the agent has no direct understanding of the topic being discussed except for that provided by the meeting agenda. Although topic understanding is helpful in assessing the relative importance of certain individuals in the CE process, it is prohibitively dif®cult to realize with current knowledge understanding technology. This dif®culty is addressed by specifying issue owners for various stages on the meeting agenda. This mapping should indicate the relative importance of the user towards the resolution of a speci®c design con¯ict. For learning about the user, the agent requires methods for machine capturing and generalizing data about the user [25]. The following issues need to be considered to achieve this goal: ² To capture a good user pro®le, the CAIRO system needs to learn diverse data about the user, which includes personal and login information, interests, expertise, and decision-making. Most of such data has to be assimilated while the user is interacting with the CAIRO system. The


211

Fig. 8. CAIRO hallway interface for entering forums.

agent will act as an observer of the user capturing data needed for its learning engine, as the user interacts with CAIRO. ² The methodology has to consider generalizing knowledge about the user. The system will create rules that will govern common user interests. It is expected that the system will use the rules learned about the user preferences to adapt the interface and customize the conducting of meetings. Due to the diverse paradigms in machine learning techniques, and also in order to capture both statistical and rule-based knowledge about the user, the best approach to effective learning is to use a combination of techniques. ² A memory is also required to track user interests and involvement during different meetings. In order to capture preference and expertise within current interactions or project, the agent should use a short-term memory model. In addition, a long-term memory model will be required for a more generalized rule set about user's decision making and preference that can be used across projects. The various components of the CAIRO system were constructed as part of a prototype implementation. The prototype implementation is constructed in Java to cater to different operating platforms common in distributed design meetings. The various technologies described in this section can be best illustrated by a running example taken from a typical CE scenario. The next section describes the example in details. 4. Sample session A good way of explaining the functionality of the CAIRO system is to walk through a sample meeting using CAIRO. Because prototype demonstrations are crucial in presenting research results, part of this research effort resulted in the development of a demonstration script. The script provides a way for anyone interested in understanding the features of the CAIRO system to do so. By going through an automated, pre-scripted meeting, users can develop a better comprehension of the capabilities of the CAIRO system, as well as gain an idea of the possible applications for the

system. The following sections describe a sample meeting session using the CAIRO system. The scenario played out in the script demonstration involves a distributed group of structural engineers. The team is comprised of four team members Ð `Karim', `Lucio', `Feniosky' and `Benjamin' Ð and is headed by `Karim'. The group needs to convene to discuss a problem with a joint connection on a recently constructed building. Due to time and cost constraints, the members feel that the problem, although quite important, does not warrant an inperson meeting. For these reasons, they decide to use the CAIRO system to discuss and hopefully arrive at a solution for the joint problem. 4.1. Setup The administrator for the meeting, `Karim', informs the other group members via e-mail that the group will be meeting on the CAIRO system to discuss the joint problem with the recently constructed building. Before collaboration can be conducted via CAIRO, a few simple setup things need to be done. First, the nameserver needs to be running on a computer connected to the Internet. As described before, the nameserver is much like a web server. However, instead of providing web pages, it provides a list of available forums to possible users. In addition to including in his e-mail announcing the time for the meeting, `Karim' would include the Internet location of the nameserver. This is analogous to the real world process of deciding what building to hold a board meeting. The second setup requirement is to provide a forum. The forum allows users that have entered a communicate and collaborate as need be. `Karim' creates a forum called Joint_Problem and registers it with the nameserver. The title of the forum would also be included in the e-mail. This is analogous to telling all the members in what room number the meeting will be held. While creating the forum, `Karim' would also have to establish an agenda for the meeting using the agenda management tool. 4.2. Entering a forum As the time arrives for the meeting, the users start to log into the CAIRO system. As can be seen in Fig. 8, the CAIRO user interface presents the user with the feeling of

212


Fig. 9. Agenda interface for the joint_problem meeting.

a hallway. Available forums on the nameserver are represented as doors in the hallway. Users can move up and down the hallway to view all the available rooms. Selecting one of the doors, allows the user to enter rooms. CAIRO provides an animation of a door opening to give the real world implication of actually entering a room. Continuing with the demonstration, `Karim', `Lucio', and `Feniosky' enter the meeting on time.

menu will appear with several options including a TalkEveryone choice. However, users wanting to communicate with a particular member can click on the image of the person. Another menu will appear with more options including a Talk option. As mentioned before, depending on the current meeting control strategy, communication requests may be immediately granted, or they may be sent to the chairman to make the decision of granting the requests.

4.3. Starting the agenda

4.4. Feedback

Despite `Benjamin's' apparent absence from the meeting, `Karim', the meeting chairman, decides to begin the meeting. Because the agenda has already been preset in the CAIRO system, all `Karim' has to do is display the agenda and start the agenda. CAIRO will then take the members to the forum synchronously through the meeting. The ®rst item on the agenda is Ìntroductions'. As can be seen in Fig. 9, the agenda also contains more information about the each agenda item. Meeting participants can see who is in charge of a particular agenda item, how long the agenda item should last, and what type of meeting control strategy is being employed for that particular agenda item. In the example provided in Fig. 9, the agenda item Joint Connection Problem uses the chairman meeting control strategy. In this strategy, the chairman of the meeting, in this case `Karim', can communicate with other meeting members as s/he so desires. However, if other members wish to communicate, they must ®rst receive permission from the chairman. CAIRO provides pop-up menus as a means for talk requests. Users wishing to communicate with everyone in the meeting can click on the table. A

To illustrate the pop-menu functionality. Figs. 10A±D have been included. Fig. 10A shows a user, `Feniosky' on the right, requesting to talk to everyone in a chairman meeting control strategy. Due to the rules of the chairman control strategy, the request goes to the chairman of the meeting, `Karim' on the left. Fig. 10B shows that the meeting member `Feniosky' is highlighted in red (although this cannot be seen due to lack of color), meaning that `Feniosky' is requesting to talk. The highlighting is used to grab the attention of the chairman, making the request easily known. As the chairman, `Karim' now has the option of accepting or denying `Feniosky's' request. To do so, `Karim' is now presented with another pop-up menu listing his current options, including Accept and Deny. The pop-up menu implementation gives the chairman the opportunity to respond to the request as s/he pleases. Much like a board meeting, when members show interest in talking, the request is not always immediately acknowledged. Finally, `Karim' decides to grant the request to `Feniosky'. Fig. 10D displays the resulting interface after the request has been granted. Two things should be noted


from the ®gure. First, on `Karim's' interface on the left, `Feniosky' is highlighted in green (although this cannot be seen due to the lack of color), letting `Karim' know that `Feniosky' is talking to him. Second, on `Feniosky's' interface on the right, a black dot has appeared next to `Karim's' name as well as all the other names in the meeting. This allows `Feniosky' to know with whom he is talking. CAIRO also provides the same sort of requesting with color indications for talk and side conversation requests. 4.5. Means for collaboration No matter how much structure has been built into the CAIRO system to control and manage the distributed collaboration process, the process as a whole would be futile without tools for communication. In real world meetings, tools such as black boards, overhead projectors, and note pads are used to share information. CAIRO includes tools for communication and collaboration. Currently the CAIRO system supports a couple of collaboration tools. The ®rst is a message board that is designed for passing text messages across the Internet to other meeting members. The CAIRO whiteboard behaves similar to other drawing tools such as XPaint. An added feature is that, when appropriate, meeting members can see what is being drawn on the member's whiteboards. In addition, the overall design for the implementation for the CAIRO tools was that of a plug and play nature. A perfect example of the plug and play architecture is the scheduling tool. This tool allows users to edit scheduling information on a sever and receive graphical updates of the information. This tool, which is not crucial for the functionality of the CAIRO system, was easily incorporated into the system. Mechanisms to include other tools like AutoCADw for structural engineering design are being currently tried out to extend and customize the usability of the CAIRO system. 4.6. Collaboration through CAIRO As the meeting continues from the ®rst agenda item to the second, different members of the meeting request to talk. At the start of the second agenda item, `Feniosky' proceeds to describe the problem with the joint on the wall in the building. By presenting diagrams on the whiteboard, along with written descriptions through the message board, he is easily able to explain the situation to the other members of the team. Fig. 11 shows `Feniosky's' interface at this point in the demonstration. Following the problem de®nition by `Feniosky', the allocated time for that particular agenda item has run out. The CAIRO system, through the agenda agent, pops up and suggests that the meeting proceed to the next agenda item. Since `Feniosky' has ®nished, `Karim' accepts the suggestion and moves on to the next agenda item. The subsequent agenda item calls for a discussion and an exploration for alternatives to the current joint setup. This particular agenda item employs the free style format for its meeting control

213

strategy. Here, members can speak up and contribute freely to the discussion at hand in order to come up with a solution to the problem. During the discussion, `Lucio' requests a side conversation with `Feniosky'. `Feniosky' accepts, and `Lucio' begins explaining what he thinks is a viable solution for the joint problem. Before `Lucio' can start to explain, `Feniosky' suggests that they really should share this information with everyone else in the meeting, namely `Karim'. By using the tab features on the CAIRO interface, `Lucio' and `Feniosky' return to the main meeting room where `Lucio' proceeds to propose a solution of adding a kicker to support the joint connections. 4.7. Agent interaction As `Lucio' prepares to describe his solution for the kicker, he sends a message via the text board indicating that he would like to explain something to everyone. The agent (see Fig. 12) then interrupts the meeting and suggests to the chairman of the meeting that the members switch to a lecture meeting control strategy because `Lucio' would like to explain or present information to all the users. `Karim', as administrator and head of the meeting, likes the idea and accepts the agent's suggestion. The meeting now proceeds in a lecture mode with `Lucio' presenting his solution to the joint problem. Fig. 13 indicates that the meeting has switched to a lecture control strategy, and `Lucio' continues with his solution. During the presentation by `Lucio', which apparently is taking longer than the allotted time on the agenda, the agent pops up again, suggesting that the members of the meeting move on to the next agenda item. This time, `Karim' feels that the agent's suggestion is inappropriate and rejects the suggestion. `Lucio' ®nishes his presentation. `Karim' now decides to move on to the next agenda item where are all the members will decide upon a solution for the joint problem. After some discussion, it is agreed that the suggestion from `Lucio' is a good one. The members quickly check the effect of that design change on the overall schedule of the project using a third-party schedule tool that was developed independently of the CAIRO system, but was easily added due to the plug and play nature of the system. Fortunately, adding the proposed modi®cation will have no serious effect on the schedule. Fig. 14 displays the CAIRO system with common drivers. 4.8. Replay As the members of the meeting are about to adjourn, the fourth and ®nal team member, `Benjamin', enters the forum. `Benjamin', enters the forum. `Benjamin' apologizes for being late. `Karim', a little irate, but always a consummate professional, excuses `Benjamin'. `Benjamin' is a little concerned that he has missed the entire meeting. Fortunately, the CAIRO system also aims to enable collaboration asynchronously. All events in a

214


Fig. 10. (A) Talk to everyone from `Feniosky'. (B) Request received by the chairman. (C) Chairman accepts request from `Feniosky'. (D) Resulting interface for the chairman and `Feniosky'.


Fig. 10 (continued).

215

216


Fig. 11. CAIRO client-side user interface.

Fig. 12. Agent interaction.


217

Fig. 13. Lecture control strategy.

forum are logged to ®le. If the forum receives a replay request, the log ®le is `played', showing all events and actions to the clients. `Karim' informs `Benjamin' that he can select whatever agenda item he is interested in viewing, and by choosing the replay feature on the agenda, he can witness all communication and all tools used during that particular agenda item. As `Benjamin' reviews the meeting, the other three meeting members leave and return to their other work. `Benjamin' is then able to catch up on all the problems, discussions, and decisions that occurred during the meeting. If need be, anyone interested in learning more about the joint problem can log on to the CAIRO system, enter the forum and replay the entire meeting. The CAIRO system could then be used in other aspects of the project including redesign, cost ¯ow analysis, or any other part of a project that requires meetings and collaboration. In general, the CAIRO system is designed to be used in the manner illustrated by this example Ð to provide its users with an alternative to in-person meetings in an effort to save time and monetary costs. The goal of this demonstration is to provide information about all aspects of the CAIRO system. It should have shown the capabilities of the system, displaying more of the CAIRO features, as well as explaining how the system can be used. Ultimately, the demonstration shows that the CAIRO system not only amply facilitates distributed collaboration, but also improves the quality of the collaboration.

5. Concluding remarks The CAIRO system discussed in this paper provides effective mechanisms for enhancing the distributed design process. The CAIRO system removes the management burden of enforcing group interaction protocols and maintaining focus within a distributed group of designers and engineers. It also automates and signi®cantly enhances group memory, which is necessary to ensure accountability and reduce duplicated effort. All these support mechanisms enhance communication within the distributed group allowing effective distributed design. The CAIRO system is currently being tested in pilot studies at select academic and industrial locations [25,26]. Preliminary results from these pilot studies have indicated that the need for techniques and strategies for meeting facilitation and group memory recording are essential in the distributed processes of today. The CAIRO system enforces many of these strategies in a distributed environment thereby reducing time, personnel, and training expenses. In addition, this paper has presented models of design team interaction and their application to distributed CE environments. Furthermore, an experimental CE experience is presented as an illustration of the use of a variety of interaction tools in these settings. On a higher level, group design processes were also reviewed for the example to determine appropriate computer support for these processes. The structures of groups and

218


Fig. 14. CAIRO at work.

meetings, in addition to the norms that govern their discussion have been decomposed and computer support for group and meeting structuring as well as coordination has been developed. Meeting agenda structuring tools and group de®nition tools have been developed based on the criteria outlined in management literature to provide effective meeting support in an online environment. These tools enforce meeting membership, agenda ¯ow and ¯oor control on distributed collaboration in concurrent design meetings. Additional AI based agents have also been implemented to provide facilitating services in the proposed CE environment. These agents detect dysfunctional meeting processes and meeting transition queues from user input. One agent senses the amount of time distributed users spend waiting to communicate with the group and changes the ¯oor control process to provide an adequate forum for interaction. Another agent detects keywords that imply a shift in topic discussion or style of discussion to automatically change agenda stages or ¯oor control strategies. Additionally, the online meeting environment provides simple `wizards' to generate standard meeting agenda templates. The CAIRO system provides the group support discussed above, in addition to a robust multimedia communication infrastructure. CAIRO provides the ability to add arbitrary devices to be shared among the conferencing individuals. Devices may be added by adhering to the CAIRO Applica-

tion Programming Interface (API). The system provides synchronization of the multiple media devices and enforces group coordination control over each of the devices. Algorithms have been developed to maintain intra-media synchronization across a non-deterministic packet switched network (Internet) and to ensure limited communication bottlenecks [20] Furthermore, the system provides automated documentation of meeting interactions and browsing features for random-access retrieval of meeting proceedings. This is an effective mechanism for updating late or absent members on the activities and conclusions of the team. Acknowledgements The authors would like to acknowledge the support received from Kajima Corporation of Japan. The research work presented here was partially funded under the IESLKajima Program at MIT. References [1] Senge P. The ®fth discipline. Currency/Doubleday, 1995. [2] Winner R, Pennel J, Bertrand H, Slusarczuk M. The role of concurrent engineering in weapon systems acquisition. IDA Report R-338, Institute of Defense Analyses, Alexandria, 1988.

F. PenÄa-Mora et al. / Arti®cial Intelligence in Engineering 14 (2000) 203±219 [3] Evans B. Simultaneous engineering. Mechanical Engineering 1988;110(2):38±39. [4] Turing J. Managing concurrent engineering: beyond time to a market. A de®nitive guide to improved competitiveness in electronics design and manufacturing. New York: Van Nostrand Reinhold, 1992. [5] Huthwaite B. Strategic design: a guide to managing concurrent engineering. The Institute of Competitive Design, Rochester, New York, 1994. [6] Prasad B. Concurrent engineering fundamentals. Volume 1: integrated product and process organization, Prentice Hall International Series in Industrial and Systems Engineering. New Jersey, 1996. [7] Maliniak L. Teamwork is the key to the concurrent design. Electronic Design 1991;39(1):41±43. [8] Bhat RR, Gauchel J, Van Wyk S. Communication in cooperative building design. CAAD Futures '93, Pittsburgh, USA, 1993. p. 481±93. [9] Qian D, Gross M. Collaborative design with netdraw. Proceedings of the Eighth International Conference on Computer Aided Architectural Design Futures, Atlanta, USA, June 1999. p. 213±26. [10] Krishnamurthy K, Fruchter R. Feedback on observation of communication among design communication among design consultants in systemix project. Working paper no. WP 021, Center for Integrated Facility Engineering, Stanford University, CA, 1992. [11] Maurer F. Project coordination in design processes. Proceedings of WETICE-96, Stanford, CA, June 1996. [12] Proceedings of the CE94 Concurrent Engineering: Research and Applications Conference, Concurrent Technologies Corporation, Pennsylvania, 1994. [13] Levitt RE, Kunz JC, Luiten GT, Fischer MA, Jin Y. CE4: concurrent engineering of product, process, facility and organization. Technical report no. 104, Center for Integrated Facility Engineering, Stanford University, CA, 1995. [14] Proceedings of the CE95 Concurrent Engineering: A Global Perspective Conference, Concurrent Technologies Corporation, Pennsylvania, 1995. [15] Hyvarinen J, Katranuschkov P. Product data management methods in a concurrent engineering environment for AEC. Abstracts of the Fourth Workshop of the European Group for Structural Engineering Applications of Arti®cial Intelligence (EG-SEA-AI), Lathi, Finland, 1±2 September 1997.

219

[16] Fischer M, Kunz J. Data sharing and control in AEC software integration. International Journal of Construction Information Technology 1995;3(2):77±90. [17] Chen YM, Liao CC, Prasad B. A systematic approach of virtual enterprising through knowledge management techniques. Concurrent Engineering: Research and Applications 1998;6(3):225±44. [18] Anumba CJ, Kamara JM. Concurrent engineering in construction: state of the art, advances in concurrent engineering. In: Chawdhry PK, Ghodous P, Vandorpe D, editors. Proceedings CE99, University of Bath, UK, 1±3 September 1999. p. 461±70. [19] Clayton M, Teicholz P, Fischer M, Kunz J. Virtual components consisting of form, function, and behavior. Automation in Construction 1999;8:351±67. [20] Hussein K. Communication facilitators for a distributed collaborative engineering environment. Master's thesis, Massachusetts Institute of Technology, 1995. [21] PenÄa-Mora F, Sriram D, Logcher R. Design rationale for computer supported con¯ict mitigation. AI EDAM (special issue on concurrent engineering) 1995;9(2). [22] PenÄa-Mora F, Hussein KM. Proactive meeting management for distributed collaborative design. Advances in Engineering Software 1998. [23] PenÄa-Mora F, Hussein K, Sriram D. CAIRO: a system for Facilitating Communication in a distributed collaborative engineering environment. Journal of Computers in Industry (special collaborative engineering issue) 1996;29:37±50. [24] PenÄa-Mora F, Hussein KM. Interaction dynamics in collaborative design discourse: application in computer mediated communication. Microcomputers in Civil Engineering 1997. [25] Hussein K. Computer supported interaction in distributed design. Doctoral thesis, Massachusetts Institute of Technology, 1998. [26] Benjamin K. De®ning negotiation process methodologies for meeting environments. Master's thesis, Massachusetts Institute of Technology, Department of Electrical Engineering and Computer Science, 1998. [27] Doyle M. How to make meetings work. Berkeley Books, 1993. [28] Fisher R, Ury W. Getting to yes. Baltimore, MD: Penguin Books, 1991. [29] Maes P. Agents that reduce work and information overload. Communications of the ACM 1994;37(7):31±40.