collaboration services, including multimedia mail ... sources and services will be multimedia \notebooks\ ..... be e-mailed for automatic replay at receiving work-.
In Post-Proceedings of the IEEE Infrastructure for Collaborative Enterprises (CDR-TR #19930507)
1
SHARE: A Methodology and Environment for Collaborative Product Development George Toye, Mark R. Cutkosky, Larry J. Leifer, Center for Design Research Stanford University Stanford, CA 94305-2232
Abstract The SHARE project seeks to apply information technologies in helping design teams gather, organize, re-access, and communicate both informal and formal design information to establish a \shared understanding\ of the design and design process. This paper presents the visions of SHARE, along with the research and strategies undertaken to build an infrastructure toward its realization. A preliminary prototype environment is being used by designers working on a variety of industry sponsored design projects. This testbed continues to inform and guide the development of NoteMail, MovieMail, and Xshare, as well other components of the next generation SHARE environment that will help distributed design teams work together more e ectively.
1 Introduction The SHARE1 project is broadly concerned with how information technology can help engineers develop products. Increasingly, product development involves teams of engineers from multiple organizations working together over networks, supported by computation and information services. In anticipation of this future, we are studying engineering teams operating in a prototype of such an environment. Specifically, we engage design teams who conceive, re ne and prototype systems for industrial sponsors as part of a 9-month long graduate course. The course is an uncompromising testbed for evaluating new tools and methodologies, and it provides us with a stream of information to capture, reduce and organize. The short 1 The work presented here is being carried out under the Department of the Navy Contract N00014-92-J-1833.
J. Marty Tenenbaum, Jay Glicksman Enterprise Integration Technologies Palo Alto, CA 94301
design cycle also promotes information sharing and reuse { between team members, between teams, within a single year and across multiple years. Our experiences lead us to view team design as a process of reaching a \shared understanding\ of the domain, the requirements, the artifact, the design process itself and the commitments it entails. The understanding emerges over time as each team member develops an understanding of his or her own part of the project and provides information that allows others to progress. The process involves communication, negotiation and community learning, activities not well supported by current CAD tools. This paper provides an overview of SHARE and reports initial progress. We focus on three central issues emanating from the view of design as shared understanding. First, what precisely do we mean by a shared understanding? Second, what tools can help a team reach such an understanding and capture it for subsequent use by themselves and others? Finally, how can the resulting design record be exploited, for example to reduce rework and facilitate redesign?
2 Motivation and background Today's CAD systems do not support the tasks on which engineers spend the most time: gathering and organizing information, communicating with clients, suppliers and colleagues, negotiating tradeo s, and using each others' services. Engineers spend weeks locating catalog items, consultants, analysis tools, and production facilities. They redo analyses and manufacturing plans because it is dicult to retrieve relevant examples from the past, or because the examples lack sucient context or detail to adapt them to the circumstances. Sometimes, they forego analysis alto-
2
INTERNET Modeling
Entry Order
Online Parts Catalog
Rap id P roto typin g
ion ulat Sim
Email
Τησιαλιϕ σαλκιο δφ σιεθρ ασκλ σλκφ σδ
Bearing Class
1. Bearing slio sijoasf siloiwr8 ls
2. salk 28023 iouvzlkl oal uioso
3. Ajsdj sjdj sjue wqola oirhje osie
4. AS sfd siioq OPpas PP; dsio;d
5. aslk 2ep eoj;y nspdg dsizji 9ixd
6. als soiel gphllytklyu i iledui sk
7. sld lsjfkd ksdl.
Timken Co.
Timken Co.
ΝοωΣΗΑΡΕ ισ ωελλ οργανιζεδ δφ σιεθρ ασκλ σλκφ σδ
DATA
Timken
Catalog
Part # xxx-xx-xx
Lift Ratio
Euler Column formula π 2E I
P = cr l 2
Space/Chord Ratio
Experimental Setup 1. Use digital storage oscilloscope to view output
of strain gage. Deflect sample by 6mm ± and release. View transient response at
settings of 10mv/div and 10ms/div. Measure
period of vibration and estimate damping
constant.
2. Measure thickness of block sample using
calipers.
3. Repeat steps 1,2 and collect data for 1000
iterations.
4. Calculate and plot natural frequency of material
over the 1000 iterations.
5. Plot material thickness measurements over
the 1000 iterations.
bearing
1mm
Ηεαδ Ηονχηο To:
Λιττλε Πεον From:
Subject: Μασσιϖε ∆εαδλινεσ Message: Τηισ ισ α ΧΨΑ µεµο οφ µαϕορ προπορτιονσ το λετ εϖερψονε κνοω τηατ Ι αµ νοτ ατ φαυλτ. Ιτ ωασ νοτ µψ φαυλτ τηατ εϖερψτηινγ ισ βεηινδ σχηεδυλε. Τηε σχηεδυλε
Results
ωασ νεϖερ α ρεασοναβλε
129.8912
980.2374
498.8342
689.3483
890.3249
348.90554
490.84390
Weinig's Results Lift Ratio
ονε το σταρτ ωιτη. Ψου ωαντεδ α
129.8912
980.2374
498.8342
689.3483
890.3249
348.90554
490.84390
5 µαν ψεαρ προϕεχτ φινισηεδ ιν λεσσ τηαν 3 δαψσ. Νο ονε ωιτη ανψ ρεασοναβλε ιντελλεχτ ορ σανιτψ χουλδ ϕυστιφψ τηισ σχηεδυλε.
Space/Chord Ratio
CNC Code Euler Column formula π 2 E I
P = 2 cr
2
= 3.141592 • 30 x 10
l
96
= 2.28 x 10
6
• 7.090
2
5
© George Toye
Figure 1: The SHARE vision gether because the cost of learning new tools exceeds their apparent worth. Then, when the design is back from fabrication, it is back to the drawing board because of an earlier failure to communicate some interface convention or constraint. The consequences of all these diculties are well documented, and include costly engineering change orders, delays in procurement and fabrication of prototypes, high reject rates and high maintenance costs. To overcome these diculties, we propose an open, heterogeneous, network-oriented environment for concurrent engineering. The environment enables engineers to participate on a distributed team using their own tools and data bases. Speci cally, it provides:
familiar displays that put information at engineers' ngertips, including on-line notebooks, handbooks, requirements documents, and design libraries;
collaboration services, including multimedia mail and desktop video conferencing, that enable team members to communicate and share tools and data; on-line catalog ordering and fabrication services, with information about pricing and shipping and bid solicitations, leading to delivery of components without numerous phone calls to clarify the designers' intent; specialized services for simulation, analysis and planning, (e.g., cost estimation, dynamics simulation) and shared engineering knowledge bases; a distributed product data management service that accepts postings from on-line tools and services, and maintains dependencies so that when changes occur, the right people are noti ed, tools invoked and sources consulted;
an integration infrastructure that enables heterogeneous design tools and databases to interoperate transparently across platforms, creating a shared project environment. The windows onto this world of networked resources and services will be multimedia \notebooks\ in which to capture and organize information about a project: CAD drawings and solid models, audio notes, sketches, spreadsheets, pages from handbooks and catalogs, animated simulations, mail, excerpts from video conferences, and so forth (see gure 1). What will life be like for an engineer on the Internet? He or she will browse on-line handbooks for relevant components or design models, and submit them to remote services for simulation or analysis. Interesting designs will be copied and pasted into the notebook, and annotated by adding hypertext links to related speci cations, data, analysis tools, and components. These links represent constraints, rationale, and dependencies, some of which may point to entries in colleagues' notebooks. Notebook pages will be exchanged with colleagues and inserted into shared project notebooks. Users will navigate this distributed information web using browsing and search tools. Alternatively, they can invoke agents to keep track of dependencies and alert them (or other agents) to changes. Design con icts that require negotiation will be resolved using multimedia e-mail or a notebook video conference. When a design is ready for fabrication, its speci cations will be shipped over the network, perhaps through a broker, to the appropriate production, and procurement services. While the above scenario may sound like science ction, the key elements exist today, at least in a rudimentary form. Over the next few years, we will be exploring the research issues associated with creating such an environment for our graduate design teams. The goal is a system that becomes one's preferred work environment for collaborating on everything from proposals to detailed designs.
3 The SHARE project domain Implementation of our collaborative engineering environment is intimately tied to supporting real industrial design e orts. Our domain is ME-210, a 9-month long engineering course in which teams of designers conceive, design and prototype substantial electromechanical systems for industrial sponsors. The designers are typically rst or second year graduate students with one to two years of industrial experi-
3 ence. They work in teams of three with coaching from faculty, sta and volunteer consultants from industry. The projects are multi-disciplinary, combining thermal, mechanical and electrical systems, sensors, actuators, and software. As in industry, the teams have tight deadlines, must manage equipment and development budgets, engage in design reviews, and negotiate with the sponsors, vendors, and fabrication job-shops. The design process goes from requirements de nition and conceptual design to a working prototype and nal report in 9 months. The report, often running over 200 pages, is typically of more value to the sponsoring companies than the prototype because it not only documents the design, but also captures the students' experience, decision making process and knowledge relating to the project. Roughly 60% of the report consists of appendices of calculations, catalog pages and data sheets, test results, materials properties, contact logs, meeting notes and other information extracted or generated during the design. Decisions and rationale behind the nal prototype as well as ideas pursued and ultimately abandoned are also documented The design process begins with extended discussion with the sponsor about the design requirements and constraints. The design teams deliver a requirements document to the clients early in the course. However, as with all real design processes, the generation and clari cation of requirements and constraints continue throughout the design. As the design continues, information is gathered, sifted, sorted, and reorganized for presentation. The report is generated incrementally and submitted for review at the end of each academic quarter. Sections are reviewed more frequently as part of regularly scheduled design reviews. Each submission contains revised and reorganized information from the previous versions. As the teams are each working on di erent projects and not competing directly, there is more incentive to share knowledge than to hide it. Indeed, a class consensus rapidly develops concerning which tools, consultants, and handbooks are most helpful. Why ME-210?
The engineering design course provides the SHARE project with important resources. First, it is a testbed for evaluating tools, methodologies and concepts that we develop. The rapid turnover and aggressive design schedule allow us to obtain considerable empirical data over just a few years. The tight deadlines also ensure that designers will employ a new tool or
method only if it is demonstrably helpful. Second, the course provides a rich stream of design examples that cross disciplines and levels of detail, from component design and fabrication to subassembly integration. Extensive interaction takes place not only among team members but also with other teams and with the \extended team\ of sponsors, consultants and vendors. The result is a ood of information that must be captured and organized in near-real time. This coupling to real design activity provides a distinctive direction for tool development. The course also provides many opportunities for observing and abetting design reuse. Often, sponsors come back with variations on a theme that appeared during previous years. For example, a client may ask for a packaging system one year and a materials handling and inspection system to go with it the next. Today, the main source of information about previous projects is a chronologically arranged library of nal reports. Searching for relevant information is a tedious and inexact process. If a team needs information about precision assembly devices it is up to the faculty, sta and sponsors to recall which projects from which years are likely to yield something germane. Thus, one of the goals of SHARE is to replace today's inecient library of paper documents with an on-line library of hyper-documents that are easier to generate, and more useful to designers, clients, coaches and faculty.
4 The initial SHARE environment To promote electronic information sharing and to build up an electronic library we must rst capture design information in electronic form. Our commitment to working with the design class has resulted in the following strategy for the rst year of the SHARE project: First, we promote computer use in all designcommunication-documentation activities and capture as much as possible electronically, whether by cutting and pasting an electronic mail message from a consultant, by scanning in a catalog page, or by appending a worksheet from a spreadsheet program. Second, we provide templates and commercial software to facilitate the process of structuring, organizing and sharing information. The preliminary SHARE environment described in this section is now providing us with a stream of electronic information to consider as we develop the next-generation SHARE environment described in the following section. The hardware
4 During the 1992/93 academic year, each team (and in a few cases each team member) is using a Macintosh PowerBook as a prototype window into the SHARE environment. The students are typically familiar with Macintosh based software for generating reports, preparing presentation slides and conducting spreadsheet analyses, etc. The decision to use PowerBooks was based on the experience that engineers (including the authors) are more willing to include computers in their daily activities if they are not tied to workstations, that is, if they can bring the computer to the work rather than vice versa. The commitment to \nomadic computing\ currently entails some operational compromises. In particular, episodic connectivity is achieved by connecting the PowerBooks to the campus local-talk network or by making telephone modem connections as the needs arise. Once wide-area wireless network technologies mature, such compromises will no longer be necessary. In the mean time, the PowerBook's portability and accessibility encourage its use and increase the computer based capture of design activity that would otherwise go unrecorded. Document preparation software
Designers in ME210, as in industry, resist tools perceived to be a poor investment of time. Fragile or hard to learn software is unacceptable. Practically speaking, this restricts us to a robust, capable subset of commercial quality software. The tools in uence the quantity and quality of what the designers are willing to externalize, and what we can capture. The most important software has been that used for creating the electronic design notebooks and reports. In choosing this software, trade-o considerations were ease of use, speed of launching, document transportability across platforms, ability to construct hyper-documents containing bitmaps, video and audio, and exibility in de ning and modifying document structures. The real-time aspects of design capture are also important. While distillation of information helps the designer re ect, major post-hoc reconstruction and reorganization is time consuming and distracting. Moreover, information recreation is imperfect and seldom complete. Consequently, the notebook software must be conducive not only to document preparation but also to jotting down notes after making a phone call or scanning in a catalog page. After considerable debate about the merits of different programs, FrameMaker was selected as the environment for generating notes, requirements documents and design reports. The designers use
title requirement decision opportunity priority participant question idea document reference
meeting date rationale issue action item contact author direction assumption human contact reference
Figure 2: Core tags and elds to be used in the design notebook FrameMaker primarily by interacting with templates that we provide with standard elds and a glossary for labeling key terms associated with the design process. The use of templates give documents logical structuring and consistent formatting. From the standpoint of browsing, analyzing and re-using information, we would like the templates to contain as much structure and semantics as possible; by getting the designers to organize the information (via templates) as they enter it, post-hoc analysis is greatly facilitated. However, if the templates become cumbersome or complex they will not be used readily, and may even be used incorrectly. A more subtle danger is that the templates may distort the design process itself, by predisposing designers to work with certain kinds of information that the templates handle most e ectively. The templates are still being re ned and are themselves the subject of important design tradeo s. In view of these considerations, we have limited ourselves to two generic templates and have encouraged design teams to augment these to suit their own needs. Because ME210 projects span a wide variety of engineering domains, the supplied set of elds and tags is limited to those that are generic to design activity. The rst template emulates a notebook where design information is recorded chronologically. A set of pre-de ned elds and tags helps designers to organize their notes. While the elds and tags are still under revision, our experiments have shown the following core set to be useful: Designers are prompted to enter information into pertinent elds in forms such as those for meeting notes or phone conversation logs, and to categorize their thoughts using tags such as action item, or assumption. The elds and tags de ne identifying fea-
5 Title Page Executive summary Table of Contents Table of Figures Glossary Need statement Problem statement Requirements (speci cations) Functional Speci cations (\tasks\ (what the device must do)) Physical Speci cations (\features\ (how the device does it)) External Speci cations (what the user will experience using it) Assumptions Constraints Opportunities Design Design Alternatives (N 3) Strategies (the ones you really used) Product De nition as of the Design Review Planning & Scheduling References people consulted literature accessed Budget Appendix - A -people contact records People pointers Notes from contacts and meetings Appendix - B - analysis and simulation Models Results Experimental data Appendix - C - backup data Product or component speci cation sheets Key envelop backs Appendix - D - presentations: (design review slides & brie ng view graphs) slides (always duplicate key presentation materials) view graphs handouts video (required in June) diskettes Figure 3: Design requirements report outline (top 2 levels of a 6 level outline)
tures in the document's landscape so that data can be associated with its visual appearance and location. The use of elds and tags requires little additional effort and has been shown to be an e ective navigation aid for subsequent reuse [20]. Accompanying drawings, doodles and other types of adornment aid associative recall. As with a paper notebook, the electronic notebook can have a split page layout to promote such visual indexing. The right half is lled with raw notes, and the left half is sparsely populated with tagged text and visual sketches that summarize and highlight key elements contained in the notes on the right. The second template is based upon a design requirements report outline that has been developed and re ned over several years. This outline (Figure 3) guides the designers in communicating a necessary set of information in a well-structured and consistent way. Design notes from the designers' notebooks are consulted, re ected upon and reorganized in composing the quarterly reports. Snippets are often transferred directly from notebooks to the reports. These formal documents, along with the team's PowerBook containing all supporting notes and documents, are delivered to the project sponsors. The result at the end of the rst year will be electronic documents in FrameMaker with some structure (chronological as well as by category) of the design process. All project documents will be archived onto CD-ROMs for distribution to SHARE researchers and formation of an electronic design library for subsequent years. Other Software Tools
Aldus Persuasion (a presentation tool), AEC Fastrack (a time-line management tool), Claris MacProject (a critical path management tool), Microsoft Excel (a spreadsheet tool), Ashlar Velum (a 2 F(1,2) D drafting tool), and Wolfram Research Mathematica (a modeling tool) are other Macintosh programs used by the students. We supplement these applications with an electronic mail and le server environment. These connectivity tools facilitate the electronic sharing of information and documents among students, teaching sta , coaches, and sponsors. Electronic Mail
Students are strongly encouraged to use electronic mail. There is extensive use of mailing lists as a primary means of interaction with fellow team members, coaches, teaching sta and sponsors. Electronic mail is an e ective communication medium for the students and teaching sta , given very diverse schedules. Use
6 of this medium results in shared information that can be incorporated into the electronic design records. Our mail service is based upon Eudora for the Macintosh [12] and popper - a POP [27] server on a UNIX mail host. Together, they simulate an extended mail network. Designers \check in\ at least once a day at which time queued messages are transmitted to their PowerBooks, and previously composed messages are sent out from the PowerBook to the SHARE mail environment. Because Eudora supports both network and telephone connections for e-mail transfers, the \checkin\ can be done from remote sites using PowerBook modems. Eudora helps students organize e-mail messages into hierarchically arranged mailboxes. It also provides a mechanism for embedding application documents into messages so that they too can be shared. File Server
A le server on the local area network provides transparent backup and shared access to les. This virtual le server based on CAP [17] software maps the Macintosh le system onto a UNIX workstation. By overlaying the le systems, workstation software tools can operate on Macintosh design documents. For instance, an e-mail service has been created (using ServiceMail, as described in the next section) so that les can be retrieved from and placed on the le server via a telephone connection to any Internet e-mail host. In the future, we will also provide version control and change noti cation to reconcile les using this virtual le server mechanism. Privacy
The issue of information privacy becomes increasingly important as more activity based information is recorded and shared. Visions of big brother are close at hand. At this time, within the context of our ME210 setting, we have adopted a conservative policy of accepting only voluntary contributions of documents. This means, for example, that an e-mail user must actively add the designated message archives to the recipient list for any globally sharable messages. Similarly, only voluntarily submitted les are globally shared with SHARE researchers.
5
The Developing SHARE environment
In this section we describe our next-generation SHARE environment, still under development, that will enable engineers to work together over the Inter-
Macintosh PowerBook
ME210 ENVIRONMENT EU DO RA CA P
7
REQUIREMENTS DOCUMENTS & NOTES
UNIX Workstation Mail Host & File Server
TEMPLATE: notes
TEMPLATE: req. doc
Design Knowledge Capture
© George Toye
Figure 4: ME 210 Computing and design knowledge environment net. SHARE's tools and services complement existing engineering tools in three ways: 1) they facilitate the real-time capture, annotation and structuring of information associated with product development so that it can be preserved, retrieved and shared; 2) they support communication and collaboration among engineers separated by time and physical location; and 3) they enable the specialized tools used by various members of a development team to inter-operate and share data.
5.1 Architecture The top level architecture of SHARE is a set of agents interacting as peers over the Internet. (See Figure 5). Each agent can represent one or more of the following: a designer and his personal CAD tools, a database or other information service, a computational service that supports engineering or the engineering process. The agents exchange information and services using a simple command language [13] and representation for multimedia information [5]. The messages are sent using standard e-mail and TCP/IP transport services. E-mail serves as the primary medium for both hu-
man communication and tool integration. Engineers use e-mail routinely for discussions and information exchange. Computer agents can too. Using structured messages, they can request information and services from other agents, communicate results, notify agents of design changes, and so forth. E-mail has a combination of characteristics that make it well-suited for integrating loosely coupled applications in wide-area networked environments. Most importantly, e-mail is already pervasive and familiar to large numbers of designers. It inter-operates seamlessly across thousands of networks and hence is demonstrably heterogeneous and scalable. Second, recent standards in multimedia e-mail make it easy to exchange compound documents containing text, images, audio, video, and programs. Third, it's relatively easy to wire existing applications up to e-mail. Finally, e-mail's explicit asynchrony matches how engineers prefer to work; publishing design changes and \checking in\ for change notices at will allows them to feel in full control of the design process [25].
Concurrent Engineering Product & Process information Management Services
Version Managers
DIS
Constraint Managers
8 Design Services Agents
MATHEMATICA MATHEMATICA MATHEMATICA MATHEMATICA MATHEMATICA MATHEMATICA MATHEMATICA
Information Services
Libraries Databases Catalogs WWW WAIS
REDUX
Link Managers
Internet
DIS Facilitator client ServiceMail
DIS Facilitator client ServiceMail
NoteMail XShare MovieMail
NoteMail XShare MovieMail
ServiceMail DIS Facilitator client
NoteMail XShare MovieMail
SHARE © George Toye
Figure 5: Application-oriented view of the SHARE architecture
5.2 Core Tools and Services Zooming in on the shaded tear-drop in the lower left corner of Figure 5, the Share environment consists of three classes of tools: NoteMail and DIS, which help engineers capture and manage product information; MovieMail and X-Share which help them collaborate with colleagues; and ServiceMail and Facilitators which enable their tools to inter-operate and invoke remote services.
5.2.1 Capturing, structuring and sharing information NoteMail
NoteMail is a tool for creating, viewing, and sharing multimedia engineering documents in a network environment. It combines the functions of an engineering notebook, hypermedia browser and authoring environment, mail tool, and le application manager. Engineers use NoteMail to construct multimedia messages documenting their thoughts. These messages contain information (either copied or referenced) from any on-line source, such as handbooks, catalogs, CAD tools, simulations, e-mail and video conferences. Messages can also contain programs so that, for example, recipients can redo analyses and simulations with
their own parameters. Messages are inserted in chronological order as pages in an electronic \design notebook\. These pages can be marked up and annotated; items of information can be linked to related items on other pages. The result is a personal hyper-document that captures and structures an engineer's knowledge about a project. Selected information can be shared by e-mailing pages to other engineers or to a central project repository, complete with embedded reference pointers and hyperlinks. What emerges is an Internet-wide information web that documents and organizes the shared understanding of an entire engineering team. NoteMail messages are formatted in MIME (Multipurpose Internet Mail Extension), the Internet standard for multimedia mail [5]. This enables them to be sent as ordinary e-mail and read using any MIMEcompliant mail reader (such as Bellcore's public domain Metamail reader). MIME is an extensible standard. We have de ned a new \Format\ data type that captures and preserves the spatial arrangement of the information items on each NoteMail page. NoteMail also exploits MIME's external body reference feature. Messages can remain small because they consist mostly of pointers to externally stored data; the data is retrieved only when a page is viewed or edited. Another interesting feature of NoteMail is the open
architecture of its viewer. Unlike most other engineering notebooks and multimedia authoring environments, any application that displays through an Xserver can insert its output (audio, video or graphics) dynamically onto a notebook page through an embedded \virtual window\. When a data object or le is selected for inclusion in the notebook, the system will automatically invoke the appropriate application for displaying that item in the notebook. If the needed application is not locally resident (a likely occurrence in the case of MIME external body references), it will be located and run remotely over the network. Subsequently selecting the displayed data with a mouse will restart the original application, so that the data can be edited or updated without leaving the notebook environment. The functionality is similar to opening a le using the Macintosh Finder and automatically invoking the appropriate application for processing that le. However, applications can now reside anywhere on the Internet. We are aware of only one other multimedia editor with such an architecture, MediaMosaic [22]. Other engineering notebook projects, by contrast, lack this openness and exibility. For example, the Virtual Notebook System [6] can display only static bitmaps; GE's Electronic Design Notebook [34], which is built on FrameMaker, can run only those applications whose output formats are compatible with the handful of input formats that FrameMaker accepts. Distributed Information Service (DIS)
Multimedia engineering documents containing raw text, encoded images, audio clips, video clips, etc. can get quite large. Sending such documents via e-mail to everyone on a large design team can be costly in terms of both time and storage. Instead of transferring full copies to everyone, it is more ecient to store the components of the message in one place and just transmit a set of reference pointers. NoteMail uses an object-oriented knowledge base, known as DIS, for this repository function. Conceptually, DIS provides a centralized information storage and management service for all the data associated with a design: CAD les, e-mail messages, speci cations, simulation results, and so forth. In practice, most data remains physically under the control of the application that created it; a persistent object is created in DIS to serve as a reference pointer or \handle.\ Think of these DIS objects as encapsulating their corresponding information items. Using NoteMail, any item can now be annotated, either formally by as-
9 sociating attribute-value pairs with its object, or informally by attaching unstructured notes. The information can also be organized by adding links between objects. The links are themselves rst-class objects that can be annotated with semantic labels and constraints characterizing the nature of their dependency. For example, some links may simply be hypertext pointers, used to organize e-mail messages into discussion threads and link them to related documents and data. Others may be used to represent a formal constraints in a behavioral model. In either case, maintaining the links is the job of external applications that provide navigation, constraint management, change noti cation and other services. These applications can attach daemons to the links, which are run automatically when either side changes. In summation, what DIS and NoteMail do is help engineers capture, organize, retrieve and share design knowledge { both formal and informal { without their having to know details such as le formats and locations [14]. DIS currently uses a commercial object-oriented data base as a persistent object store. The store is accessed via e-mail or TCP/IP through a services layer that provides prede ned object classes and APIs for common design applications (simulators, CAD modelers, etc.). Service enhancements such as noti cation, constraint management, access control and version management also reside conceptually at this level. However for exibility, we have chosen to implement such functions as modular services (see Figure 5.) DIS is evolving into a fully distributed, OMG (Object Management Group) -compatible service for messaging and information sharing. What DIS provides, above and beyond OMG's basic publish and subscribe services are an e-mail CORBA API, and the prede ned class hierarchies and APIs for value-added engineering services and legacy applications.
5.2.2 Communicating and Collaborating MovieMail
MovieMail is a groupware tool that captures a workstation session as a series of screen dumps and video clips, narrated with mouse (cursor pointer) gestures and spoken comments. The \movie\ can then be e-mailed for automatic replay at receiving workstations. This is a more natural way to communicate than multimedia e-mail attachments that must explicitly be invoked by the recipient. It is particularly wellsuited for many engineering-related tasks, such as remotely demonstrating a piece of software or running a simulation and commenting on unexpected behaviors.
MovieMail builds on the spatial layout and hypertext extensions to MIME that were added to support NoteMail. In particular, MovieMail also requires temporal constraints for synchronizing separate streams such as audio and gesturing. Additionally, MovieMail requires a new video type to capture the cursor movements that direct a viewers' attention to relevant portions of the window. By making MovieMail compatible with MIME, MovieMail \documents\ can be sent as e-mail messages in the same way as NoteMail, and then inserted directly into NoteMail notebooks. Xshare
Xshare is a set of programs that provide real-time conferencing and application sharing over the Internet. Speci cally they provide interactive audio, video, text, and graphics connections among participants as well as the ability to jointly run applications. The audio and video connections will support multi-participant conferences using the new MBONE Internet multi-cast protocols [9]. The text service also supports multiparticipant discussions, in the style of Internet Relay Chat. The graphics connection provides a shared screen with transparent overlays on which participants can sketch and draw using distinctive colors. The text, graphics and application sharing services are based on XTV [1], a public domain software package for sharing X window-based applications. Application sharing relies on a single instance of the application driving multiple display servers. With this approach, applications that have machine, license, or other restrictions can still be included in shared sessions. Also, there are none of the synchronization problems that can occur when linking replicated applications (e.g. the approach taken in SRI's EDN [9]). The replication approach does have a speed advantage since less information needs to be distributed. However, wrappers or collaboration toolkits are required to adapt each replicated instance of the application for sharing. Xshare, by contrast, works without this restriction. Like all conferencing tools, Xshare is useful for interactive problem solving, brainstorming, presentations, and education. However, Xshare conferences have some signi cant advantages: they can occur spontaneously at the designers' desks; participants can share their data and tools while they converse, with very low communication overhead. In particular, users can share NoteMail and MovieMail \documents\ with colleagues during Xshare conferences, and conversely, preserve portions of Xshare conferences as MovieMail messages in their personal notebooks or the DIS repos-
10 itory. Xshare's openness, compatibility with other SHARE tools, and conformance to Internet standards, set it apart from previous video conferencing systems such as Monet [28] and IVS [15] [32]. In SHARE, all project data is connected in a giant distributed web, and can be navigated in a uniform manner, regardless of the source, format or location.
5.2.3 Inter-operation and service invocation KQML
Product development teams use many software tools, specialized for particular subsystems, engineering disciplines, and life-cycle stages. The KQML tool kit provides mid-level network services and application interfaces that enable these tools to inter-operate and share data. The KQML toolkit utilizes an agent-based federation architecture, developed under the DARPA Knowledge Sharing Initiative [11]. Information agents serve as interfaces to programs, databases and frameworks. These agents exchange information and services over the Internet using simple commands (akin to publish, subscribe and advertise), and an interlingua, here based on MIME. Special agents, known as matchmakers or facilitators, route information and requests to the appropriate recipients, based on advertised interests. When necessary, facilitators will also route information through agents that provide format translation services. Ideally, any tool should be able to plug into this infrastructure, advertise its capabilities, and immediately begin posing queries and responding to service requests. All the details, such as locating service providers, connecting to them, and performing necessary translations should be largely transparent to the application program. Our objective in SHARE is to approach this ideal by providing easily customized information agents for common engineering tools. ServiceMail
Engineers will soon be able to access a plethora of design, analysis and fabrication services over the Internet: access design libraries, run simulations on super-computers, order parts or machining services, and so forth. Such service requests can be made via e-mail. Services are requested by lling out electronic forms (e.g., purchase orders). The forms are then bundled with design les and other relevant data in a single multimedia (MIME) mail envelope. At the receiving end, incoming messages are decomposed and each component automatically routed to the appropriate person or program. The responses (invoices,
simulations, etc.) are then re-assembled and returned to the user in another multimedia mail message. The ServiceMail toolkit provides the facilities that make it easy for service providers to transform their software, databases and fabrication expertise into network services. ServiceMail will be tightly integrated with NoteMail to produce an \active\ record of the design process. Using e-mail, one will be able to retrieve CAD models from a library, send them o to a supercomputer for analysis and simulation, make design changes and have automatic e-mail change noti cations sent to interested engineers. Later, this thread of e-mail messages can be replayed with minor editing, to explore design alternatives.
6 The SHARE research program The present ME210 environment is severely constrained by the capabilities of commercial software and networking environments. In response, we are developing a number of tools and services and gathering data on ME210 tool usage. However, our vision of distributed hyper-webs, and a rich array of tools and services for navigating them, requires research in a number of areas: Studies of what designers do (their activities) Cooperative human-computer information access Design information representation and sharing Information distribution on networks Design process modeling
6.1 Studies of what designers do We are studying how designers acquire, represent, organize, and communicate knowledge. This broad research area draws upon the disciplines of cognitive psychology, discourse and language understanding, and A.I., but becomes focused if we ask about the speci c needs of ME210 teams and where they need help. The basic choices hinge on what is easy or hard for designers (versus computers) to do; for example, capitalizing on human perceptual strengths and compensating for limitations in short term memory. Our hypothesis is that the needs of ME210 groups are similar to those of engineers in industry. This hypothesis must be con rmed, but appears correct based our own experiences and those of others (e.g., [4], [21]) looking at industrial design groups.
11 A starting point is to determine how design teams in ME210 presently gather and sort through information. What sources do they consult, and how often? How do they organize what they nd and how does the organization change as the design develops? For example, design documents may start with a chronological order and later shift to a system/subsystem, part/subpart model as the design progresses. Is this primarily for the bene t of the team (e.g., to facilitate reuse out of context) or for explanation to others? These are the kinds of questions that we can start to answer with the initial SHARE implementation. It allows us to observe teams in action and examine the electronic design records they generate. One set of questions concerns the use of design notebooks, how they are created and how they are subsequently searched and re-used. For example, how and when are designers willing to add explicit structure to the information in their notebooks? Are there similarities in how di erent designers organize information so that structure can be inferred? How can this kind of structure facilitate browsing? Insight into the designers' information organization will direct the continued re nement of our information capture templates and help us better respond to the designers' generic needs. Regarding the subsequent use and re-use of notebook information, it is helpful to classify the bene ciaries into four distinct groups: 1. designers who create the original records, 2. design team members working on the same project, 3. extended design team associates (e.g. project manager, reviewer, machinist, vendor), 4. persons external to the project (e.g. external designer, corporate management, marketing, distribution, or redesigner working on similar projects). These groups di er in their familiarity with the design records, in their access frequency and in their urgency to obtain information. It is hypothesized that considerable utility can be obtained from a limited understanding of common design activities, in the absence of a deep model of the design itself. For example, while the four categories of users have di ering needs for information, they are all likely to form questions to express these needs. There is evidence to show that classi cations of questions can be used e ectively to index and search the design records for persons external to the design project [3]. Questions of the type
\What is this for>` or \Have you considered...>` appear frequently. We are compiling records of questions from ME210 to determine what can be inferred from usage patterns. More powerful browsing and retrieval methods should be possible for the originating designer and those working closely with the designer. Another prototypical searching task worth studying is the search for catalog components. For example, we want to know how often the designers search by description? By vendor names? By browsing through previous projects with similar needs? By consulting experts? Also, what does the successful search path imply for future projects? How useful would simple keyword searches be in obtaining the information from an electronic catalog?
6.2 Cooperative human-computer information access In reaching a shared under-standing, a design team employs many forms of externalized communication. This presents an opportunity and a challenge. By externalizing their ideas to form a shared understanding, the designers expose their rationale. A useful starting point is to take advantage of the knowledge restructuring and reordering that designers do with every design review and report preparation. This is a great opportunity to capture design rationale that would otherwise remain implicit in personal notebooks. However, the challenge is to record designers' thoughts in a way that preserves their exposed meaning and context. For instance, audio and video recordings of group meetings have greater delity than meeting notes; important gestures and facial expressions lose their context and meaning when recorded in any single medium. Another special concern is the treatment of non-linguistic forms such as diagrams and schematics. In engineering design, these are often our richest and most powerful information representations. How best can these potent visual cues be captured in electronic media and what kind of browsing tools can trigger human memory associations for understanding and searching?
6.3
Design information representation and sharing
A design teams' shared understanding is built up over the life of a project. It begins with individuals gathering background information, sketching concepts in their personal notebooks, and rede ning issues in their own terms. Initially, the knowledge may consist of a web of loosely structured objects that can
12 be browsed by the designer who created it. Over time, two things happen. First, concepts are gradually transformed into design models, becoming more formal and detailed. Concurrently, information is abstracted and reorganized so that it can be shared with others. As found by Bond and Ricci [4], the personal understanding of team members and the shared understanding of the team must co-evolve. Each team member develops progressively deeper models that provide just enough information for others to take their next steps. The problem at this point is to link the personal knowledge webs of team members into a shared understanding that transcends what any of them know individually2. Such sharing necessitates a common conceptual framework for communicating and organizing knowledge. Each individual brings a unique background and perspective to the team, so bridges must be built. The most basic commitment is to a common ontology, a shared vocabulary of terms and de nitions. Examples include shared coordinate frames or system diagrams { anything that helps organize the knowledge so others can nd what they need. Beginning with the information we currently can capture electronically, we are developing an ontology for classifying and organizing it. We are focusing initially on generic categories of information. These are derived in part from the templates that ME210 designers are creating today. We will add ontologies for mathematics, geometry, stress analysis and other common applications. However, our observations thus far lead us to believe that a modest set of general terms, supplemented with some project speci c terms will sustain most information sharing needs. The transformation from hyper-web to a more structured model will require the addition of semantic attributes to nodes and links to create various models for designs, design decisions and their dependencies, manufacturing processes, project schedules and so forth. We will need modeling languages and ontologies at many levels, ranging from low level encapsulated raw information objects (text, data, drawings, sounds, video) and links (dependency, constraints), to moderately structured class hierarchies (is-a, part-of), to full- edged formal engineering and manufacturing models (e.g., nite state machines, process plans). Ultimately, the sophistication of the services that can be provided depends on how much formal knowl2 The vision of integrating personal knowledge webs predates the computer age and was put forth in a prescient article by Vannevar Bush, entitled \As we may think.\ in the Atlantic Monthly (1945) [7].
edge is encoded in the representation. The relationships among shared objects can range from an unspeci ed dependency (\object X has something to do with object Y") to typed dependencies (\X is-a requirement for Y") to formal constraints (\Y varies monotonically with X\) [14]. When the precise nature of a dependency is known, automatic analysis can be applied to propagate the e ects of changes, as described in a number of research systems (e.g., [10], [19], [23], [29]). When dependencies are not captured precisely, the shared environment can at least notify designers potentially a ected by a change. The incorporation of formal models for the design artifact and constraints is an interesting framework for semi-formal representations. Experiments conducted by the DEDAL project at NASA suggest that a qualitative model of the artifact provides a suitable conceptual framework for knowledge sharing [2]. Given that no individual team member can know everything about a project, the DEDAL model is an appropriate level for representing the team's shared understanding. However, the model in DEDAL was developed after the completion of the design project and required 2 person-months to build. A challenge for SHARE is to determine how such models can be generated incrementally as a product of the team design process. Multiple models may be needed to structure the information for di erent audiences. The monumentalscope of such modeling e orts and the overarching objective of information sharing call for a coordinated e ort by the design research community. DARPA's knowledge-sharing initiative provides a role model and some useful tools for such an endeavor [11]. However, unlike the DARPA initiative, our goal is not to formalize all engineering knowledge. Rather it is to create semi-structured representations that can accommodate the range of models, varying in detail and formality, that are appropriate to di erent individuals at di erent stages of design.
6.4 Information distribution on networks An issue related to the representation of design knowledge concerns the architecture of the information network that will support it. Will the information network provided to designers be a monolithic global web of objects, or a collection of densely woven subnetworks, owned by individuals and small workgroups, which are sparsely linked to each other through simple shared models? Our experience with SHADE and PACT argue for the latter partitioned network structure. Usually, only a fraction of an individual's project knowledge is directly relevant to others on the team.
13 Moreover, one's personal network is much easier to navigate than a global web.
6.5 Design Process Modeling Another set of questions concerns modeling the design process. One starting point is to provide a model of design activities and dependencies, that allows the process to be analyzed and streamlined. Examples include tools and representations discussed by Steward [30], Eppinger and Whitney et. al. [18], and programs such as Redux [33] and gIBIS [8]. Such models can help designers keep aware of precedence constraints and preferred partial orders among design tasks. An interesting question is whether the results will be largely case-speci c or whether they can be generalized for classes of designs. We will require a design model that encompasses the communications, information gathering, and question-asking aspects of design as well as decision-making and constraint-posting. The model should allow us to express what kinds of communications acts occur, with whom and how often. Going a step further, the model should help us to explore the rami cations of such activities as question-asking. (For example, what can be inferred from the fact that a client asks the same question at several design reviews?) We also view design as a process in which formal and informal learning takes place. A question that arises from this view is whether certain organizations of information are best suited for pedagogical purposes. For example, what is the best way to arrange information when bringing a new team member up to speed on a project?
6.6 Tools Finally, we need to continue developing applications and services that facilitate concurrent engineering in networked environments. Here is a quick synopsis of projects that are already or soon will be underway:
information capture - we are evaluating and acquiring scanners, digital cameras, camcorders, digital white boards and other media to enable the ubiquitous capture of engineering information.
information organization and manipulation - we are continuing to evolve NoteMail into a tool for organizing, manipulating and viewing information on the Internet. Foreseeable enhancements
include: a low level hypermedia browser; agents that can be programmed by end-users to watch the network for selected events and take appropriate actions (e.g., notifying other agents, starting up software); and a simple pen-based interface for manipulating objects { grouping them into classes, linking them into webs, annotating them to form models, and so forth.
information retrieval - development of semiautomated power tools for abstracting, indexing and retrieving information in large networks. Information retrieval is a huge, active eld in its own right. We will explore recent techniques that exploit the middle ground between keywords and full text understanding. We will focus, in particular, on information clues that can be extracted automatically, since few engineers have time for manual indexing. Our philosophy, shared with CMU's N-Dim project, is that there are many readily extractable clues that, when combined, converge rapidly on information of interest. Examples include: who created the information, where and when, using what tool, for what project, and so forth. Such information can usually be extracted syntactically and attached to engineering documents, like the project information box traditionally included on engineering drawings. Additional paths to information are available through boolean searches on automatically generated keywords, as well as full text searches using interactive tools such as WAIS (Wide-area Information Service) [16].
Collaboration technology - SHARE will focus on issues that are particularly relevant to our deployment of Xshare and MovieMail in engineering environments. They include: evaluating the cost and bene ts of full-motion video versus MovieMail's bandwidth-conserving format of narrated slides with occasional video clips; marking video conference records interactively in real-time to designate high-value segments for design rationale; solving platform inter-operation and scaling problem so that members of engineering teams can collaborate across the Internet using their own tools.
Engineering services - Two aspects of this research are of key importance: 1) the design of engineering ontologies (a content language) to support the \knowledge-level\ exchange of information between services and 2) the incorporation of
14 existing commercial tools into services. For example, we are currently developing services for rigid-body dynamics analysis, structural analysis, and controls design and analysis using commercial tools (i.e. SDRC IDEAS, Mathematica, Matlab, Simulink) [11]. The ontologies for this domain are designed to support tool-independent communication with the services. The language used by a controls agent based on Simulink/Matlab should, for instance, be identical to that of an agent based on SystemBuild/Matrix-X. Also under development is a network service called Redux [33]. Design agents register goals, subgoals, alternatives and dependencies with Redux. The service will then keep them appraised of relevant developments, such as whether the task they are working on is overtaken by events. In the future, we expect to participate in a variety of Internet engineering services through DARPA's MADE program [24].
7 Summary SHARE is based on the view of design as a process of gathering, organizing and exchanging information. The process begins with notes, sketches, and evolves to encompass more formal representations as models are generated and communicated to others. As the proportion of formal structured information increases, the ability of automated mechanisms to help people manage it also increases. However, even toward the end of a design, the proportion of informal to formal information remains high. Consequently, SHARE focuses its initial e orts on providing tools to help people capture and organize multimedia e-mail messages, annotations, etc., that make up the bulk of typical design records. These tools will have immediate applicability in the graduate design course that is the context of our work. We want to help design teams organize their personal notebooks and use the resulting documents for redesign during the term and in subsequent years. Our focus stems directly from our commitment to providing tools that are demonstrably useful in real design environments. The graduate design course sequence provides us with a critical testbed in this regard. It also provides a rich stream of information to capture and analyze. Our goal is to capture as much as feasible, on a continuing basis. In return, we will provide students with automated retrieval, indexing and organization as these capabilities become available. We will also acquaint students with the potential of electronic design notebooks that serve both as personal and group design
records and as windows to a world of services and resources on the Internet. SHARE's vision of engineers collaborating over the Internet, tapping into a world of shared information and services, and creating vast knowledge networks that represent shared understanding, is hardly unique to design teams. It is a vision that will apply increasingly to many types of information-intensive work. Accordingly, our goal is more than just creating a next-generation design system. We are prototyping what we hope will become our own preferred environment for everyday tasks that involve locating, retrieving, viewing, ltering, indexing, organizing, modeling, and sharing information. Realizing this vision, even in the relatively circumscribed world of engineering, is a massive undertaking. It entails creating an entire information infrastructure that imposes standards on how information is accessed, modeled and retrieved, how programs inter-operate and many other things. A concerted community-wide e ort involving virtually everyone at this workshop is essential for success. Moreover, our e orts must be well-coordinated with similar framework activities in other Internet communities.
References 1 Abdel-Wahab, H.M. and Feit, M.A., \XTV: A FrameWork for Sharing X Windows Clients in Remote Synchronous Collaboration\, Proceedings IEEE Conference on Communications Software: Communications for Distributed Applications & Systems, Chapel Hill, NC, April 1991, pp. 159-167. 2 Baudin, C. Gevins, J., Baya, V., Mabogunje, A., \Dedal: Using Domain Concepts to Index Engineering Design Information\, Proceedings of the 14th Annual Conference of the Cognitive Science Society, August 1992. 3 Baya, V., et al., \An Experimental Study of Design Information Reuse\, Proceedings of 4th ASME Int. Conf. on Design Theory and Methodology, ASME, September 1992. 4 Bond, A. H. and Ricci, R. J. (1989). \Collaboration in Aircraft Design,\ Computer-Aided Cooperative Product Development., D. Sriram and R. Logcher, eds., Springer-Verlag. pp. 152-182. 5 Borenstein, N., Freed, N., \MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies\, RFC 1341, USC/Information Sciences Institute, June 1992.
15 6 Burger, A., Meyer, B., Jung, C., Long, K., \The Virtual Notebook System\, Hypertext '91 Conference Proceedings, November 1991. 7 Bush, V., \As We May Think,\ Atlantic Monthly, July 1945. 8 Conklin, J. and Begeman, M. L., \gIBIS, A hypertext tool for exploratory policy discussion,\ In Proceedings of the 1988 Conference on Computer Supported Cooperative Work (CSCW-88), Portland, OR, pp. 140-152. 9 CraigHill, E., Lang, R., and Garcia-Luna, J.J., \Environments to Enable Informal Collaborative Design Process\, 4th Annual National Symposium on Concurrent Engineering, CALS & CE, Washington '92, pp.47-62. 10 Cutkosky, M. R. and Tenenbaum, J. M. (1991). \Providing Computational Support for Concurrent Engineering.\ International Journal of Systems Automation: Research and Applications (SARA) 1: 239-261. 11 Cutkosky, M., Engelmore, R., Fikes, R., Gruber, T., Genesereth, M., Mark, W., Tenenbaum, J., and Weber, W., \PACT: An Experiment in Integrating Concurrent Engineering Systems,\ IEEE Computer , special issue on Computer Support for Concurrent Engineering, January 1993, pp. 28-37. 12 Dorner, S., \Eudora: Bringing the P.O. to Where You Live.\, version 1.3, University of Illinois Board of Trustees and Qualcomm Inc, January 1993. 13 Finin, T., et al., \Speci cation of the KQML Agent-Communication Language,\ Tech. Report EIT TR 92-04, Enterprise Integration Technologies, Palo Alto, CA, 1992. 14 Gruber, T.R., Tenenbaum, J.M., and Weber, J.C., \Toward a Knowledge Medium for Colaborative Product Development,\ AI in Design '92, J. Gero, ed., Kluwer Academic Publisheds, Norwell, MA, 1992, pp. 413-442. 15 Huitema, C., Turletti, T., \Software codecs and work station video conferences,\ Proceedings of INET 92, Kobe, Japan, pp. 501-508. 16 Kahle, B. et al., \WAIS Interface Prototype Functional Speci cation\, Thinking Machines Corporation, April 1990 17 Kim, C., Schilit, B., \Columbia AppleTalk Package for Unix\, version 6.0. 18 Krishnan, V., Eppinger, S. D. and Whitney, D. E. (1992). \Ordering Cross-FunctionalDecision Making in Product Development.\ Operations Research (Special Issue on New Directions for
19 20
21
22
23 24 25 26 27 28
29
30
Operations Management Research), 1992. Klein, M., \Capturing Design Rationale in Concurrent Engineering Teams,\ IEEE Computer, January, 1993, pp. 39-47. Lakin, F., Baya, V., Cannon, D.M., Brereton, M., Leifer, L.J., and Toye, G., "Mapping Design Information," AAAI Workshop on Design Rationale Capture and Use, AAAI-92, San Jose, CA, June, 1992. Levy, S., Subrahmanian, E., Konda, S., Coyne, R., Westerberg, A., and Reich, Y., \An Overview of the n-dim Environment,\ Engineering Design Research Center Technical Report EDRC-0565093, Carnegie-Mellon University, Pittsburgh, PA, January 22, 1993. Lin, J.K., \MediaMosaic - A Multimedia Editing Environment\, Proc. 5th Annual Symposium on User Interface Software and Technology,Monterey CA, Nov 15-18, 1992 (published by ACM Press). Lu, S. C.-Y. (1992). Knowledge Processing Tools for Concurrent Engineering Tasks. Proceedings of the 2nd International Conference on Automation Technology, Honorary Volume, 1992 Mettala, E. G., Manufacturing Automation Design and Engineering, DARPA/SISTO Program Brie ng,Arlington, VA 22203-1714. Park, H., M.R. Cutkosky, A. Conru and S-H. Lee, \Agent-Based Architecture for Concurrent Cable Harness Design,\ CDR Tech. Report 19930219. \The Common Object Request Broker: Architecture and Speci cation,\ OMG Document #91.12.1, Object Management Group, Framingham, MA, Dec. 1991. Rose, M., \Post Oce Protocol - Version 3\, RFC 1081, USC/Information Sciences Institue, November 1988. Srinivas K., Reddy Y. V., Chang L., Babadi A., Kumar V., Kamana S., Dai Z., \MONET: A Multimedia Conferencing System for Collocating People and Programs\, 3rd Annual National Symposium on Concurrent Engineering, CALS & CE, Washington'91, pp.433-441. Sriram, D., Logcher, R., Wong, A. and Ahmed, S. (1989). An Object-Oriented Framework for Collective Engineering Design. Computer-Aided Cooperative Product Development., D. Sriram and R. Logcher, eds., Springer-Verlag. 51-92. Steward, D. V. (1981). The Design Structure System: A Method for Managing the Design of Complex Systems. IEEE Transactions on Engineering Management, 1981.
16 31 H. Schulzrinne, \A Transport Protocol for Audio and Video Conferences and other Multiparticipant Real Time Applications\, Internet Draft of IETF (Internet Engineering Task Force), October 1992. 32 Turletti, T., \H.261 Software CODEC for Videoconferencing over the Internet,\ INRIA Rapports de Recherche N-1834, Jan. 1993. 33 Petrie, C., \Constrained Decision Revision," Proc. 10th Nat. Conf. on AI,San Jose pp. 393400, AAAI Press, July, 1992. 34 Uejio, W. H., Carmody, S., and Ross, B., \An Electronic Project NoteBook from the Electronic Design NoteBook\, 3rd Annual National Symposium on Concurrent Engineering, CALS & CE, Washington '91, pp. 527 - 535.
