HyCD: an Open Information Model for Cooperative Design

Transcription

1 HyCD: an Open Information Model for Cooperative Design Xu Wentao, Shi Yuanchun, Xu Guangyou Dept. of Computer Science and Technology, Tsinghua University, Beijing, , P.R.China Abstract: Cooperative design in engineering raises several requirements, such as modeling the complicated design object, hypermedia support, coordination support, open architecture for integrating current applications and modeling the process of cooperative design. In this paper, we propose an information model for cooperative design system to meet these requirements. This model, called HyCD, has three layers. The relationship layer focuses on the hierarchies and dependencies among pieces of the design object, the manipulation layer manages the view of the model, and the data layer is responsible for integration of current applications. HyCD provides explicit support for cooperation and coordination among multi-users. We have developed a cooperative design system based on HyCD, named CoDesign, of which we also make an introduction here. Finally, an example scenario is presented to illustrate the HyCD model. Keywords: CSCW, cooperative design, information model, HyCD, CoDesign. 1. Introduction Over the last decade there has been a considerable amount of research efforts in the area of CSCW, and many groupware products have been developed. The goal of them is to assist groups which undertake a common task within a shared environment for communicating, collaborating and coordinating their activities[8]. More recently, interest in computer-supported cooperative design, that is CSCW in design, grows rapidly[12]. Computer -supported cooperative design is a type of cooperative work based on shared design object. In comparison to other CSCW systems based on shared object, such as cooperative writing systems, the cooperative design system possesses many distinct features. First of all, the shared design object is very complicated. In most cases, the shared design object is interrelated so tightly that it is not completely hierarchically decomposable. Although it may be divided into smaller pieces and each is responsible by different individuals, there are still many interdependencies among components of the pieces, and unexpected interdependencies are found when solutions generated by different designers are recombined[5]. For instance, in the design of building, the size, composition, and placement of glazing, has a significant impact on the illumination parameters of intensity and glare. Design of the lighting systems, in turn, directly influences the cooling load. The groups of designers must work together, however, to avoid local optimization at the expense of the whole[5]. The design of artifacts emerge not only from interaction between the designers and the artifacts, but also from interaction with other designers and the environment. As designers collaborate, there is a need to share, coordinate and annotate a considerable amount of different, nonintegrated design media[7]. For example, in the design of building,designers use formal and informal drawings, verbal and text-based specifications, models, photographs and video to document and communicate their ideas. All these multimedia information should be integrated properly, to give all the designers a comprehensible shared information space. We propose that the computer-supported cooperative design requires an information model to give a visual representation and a semantic model of the shared object and a proper integration of the shared information. We also suggest that the information model should give explicit and effective support for the cooperation and coordination among the designers. 2. Requirements of Information Model for Cooperative Design Support for relationship There are various types of relationships among different pieces of the shared design object, such as configuration constraint, relationship between parts, constraints between parts and their parameters, interdependencies among graphic elements. Most of these dependencies are rigid, meaningful and various, so that a flexible description is needed. These

2 relationships form a complicated semantic network, variations occur on any part of the network may lead into nonconformance. An approach for nonconformance awareness and elimination is needed. Hypermedia support In order to easily interpret the complicated object, it is necessary to integrate various types of materials, such as sound, still images and animation, into the systems. These materials are not separated but associated. For example, in mechanic design systems, the CAD drawings, feature descriptions, parameters specifications, graphic models, photos and other materials of same mechanical part should linked each other to make navigation among them possible. Links should be able to express the associations not only between same types of data, but also different types of data. Support for multi-user activities The information model for cooperative design should support mechanics of simultaneous multi-user access. A closely related issue is concurrency control. Classical hard locking techniques for concurrency control are generally inappropriate. Standard read/write locks tend to be overly restrictive. The second issue is mutual intelligibility. In a collaborative effort, each participant must have some degree of understanding of the actions and intentions of the other collaborators[2]. Support for coordination In cooperative design, different individuals may heavily interfere each other if dependencies exist between the parts they are manipulating. An effective method for coordinating their activities is of great importance. The CSCW literature contains many proposals for coordination technology. Most of them based on formal models of communications and roles. In contrast, cooperative design requires coordination support closely coupled to the shared object and flexible enough to support a dynamic, event-driven environment evolving via the task to be monitored[4]. A simple example is that, in a mechanic design, the designer who is responsible for the gear must be aware to any changes occurs on the outer diameter of the shaft. Open architecture Cooperative design is not a separate, closed applications, but an open environment. It is crucial that the users can have their usual specialized design tools, which are already developed for engineering domain and, smoothly integrated in the cooperative design systems[4]. It is also crucial that the system can incorporate various types of design models such as data or product models, and data can be shared among different applications. Many of the current cooperative design systems, such as SHASTRA[10], have specially developed design tools and private models which are deeply dependent on the tools. Systems like this will meet great difficulties in consideration of practicability, portability and extensibility. Modeling design process Design is not a separate activity, like compiling a program or writing a letter that has definite start and end times. Design is a trial and error process[10]. The model should be able to describe the activities of design process. (1) Research and development activities We have developed a general open information model, named HyCD(Hypertext for Cooperative Design), which has been embodies in our experimental cooperative design system named CoDesign. HyCD has the same root with hypertext[2], Dexter hypertext reference model[1] and DHM[3]. In this paper, we first introduce the HyCD model, and then CoDesign system which demonstrates the model. At last, an example scenario is provided to illustrate cooperation beyond this model. 3. The HyCD Model The HyCD model is inspired by derived from Dexter Hypertext Reference Model[1]. The importance of hypermedia support for shared materials in engineering has been recognized[4]. Dexter is an open solid framework for hypertext, but we think that Dexter Model provides us a good idea rather than a reference model. For a detailed discussion of Dexter, see[1]. (1) Overview of the model The HyCD model consists of three layers: the manipulation layer, the relationship layer and the data layer, as illustrated in Fig.1. The relationship layer describes a database that is composed of a hierarchy of data-containing components interconnected by relational links. The data layer deals with the contained data and application integration. The manipulation layer is intended for model presentation. Two critical pieces of the model are the two interfaces: the first is anchoring which resides between the relationship layer and the data layer; the second is presentation specification which is between the manipulation layer and the relationship layer. The former provides a mechanism for addressing locations within the content of an individual component, the latter gives the relationship layer a means of specifying how to present the component network. Manipulation layer Presentation specification Relationship layer anchoring Data layer Fig.1 Layers of HyCD model

3 (2) Relationship Layer The relationship layer describes the structure of the shared object as a finite set of components. Component is the fundamental entity of this layer. A component is either an atom, a link or a composite entity made from other components. Atomic components are primitive in the layer. Their substructure is the concern of the underlying layer. Composite components are constructed out of other components. Links are entities that represent relations among components. HyCD s component possesses the following attributes: identifier: a globally unique identification of the component in the model owner: the user who is responsible for the component state: the component state presentation specification: information specifying how to present the component anchors: endpoint of links, its value points to locations within the content of the component The relationship layer focuses on the component states, various hierarchies and dependencies among the components. Component states: Every component has a state attribute. The state of a component can be: Invalid: A component is in state of invalid when the content of it is null. When a component is created, the initial state of it is invalid. Closed: A component is in state of closed when the content of it is initialized but not finished. Ready: A component is in state of ready when the content of it is finished and ready to be used by other component. A component is in ready does not mean that its content is completed finally. Changes may be made on content of a component in ready state. The state of invalid is the lowest state while ready is the highest. A component always evolves from state of invalid to ready. Hierarchies: In HyCD model, a composite component contains other components is restricted to be a directed- acyclic graph(dag). So there are hierarchies existing in the network of components. Each composite component and it s descendant components form a hierarchy and the bottoms of it are atomic components. Fig.2 shows a network of components in hierarchies. Hierarchy is a directed relationship used to model the design processes. It can take a bottom-up scheme, or a top-down scheme. Which will demonstrate different processes. When a bottom-up scheme is adopted, it can demonstrate processes which are from bottom to top, from small to large, or from parts to the whole. When an top-down scheme is adopted, it can demonstrate inverse processes. + Product 0 * - Sub product 1 Part 2 Sub product 3 Fig. 2 Hierarchies Fig.3 Generation tree of a 3D model Part 1.1 Part 1.2 Part 3.1 Part 3.2 Fig.4 Assembly tree of a mechanical product There are a diversity of hierarchies which are differentiated by the types of relationship among the under lying components. For example, in 3D model design, complicated models can be generated by set operations(union, subtraction, intersection, etc.) on simple models resulting a generation tree, as shown in Fig.3, In the tree, the root stands for a complicated model which is the goal, while the leaves stand for simple models which can be used as the starting point of the design. Another example of hierarchy is the assembly models in mechanical engineering, as shown in Fig.4. In this case, the relationship between root representing the product and the leaves representing parts is of assembly specified by assembling requirements. In order to cover all of these various hierarchies, the HyCD model places the detail information of the relationship between a composite component and it s children in the content of the composite component. The relationship layer does not make any

4 difference for different hierarchies. In order to model different processes, the HyCD model provides different orders of composite component creation. An atom can be changed to a composite component by adding child to it, in other words, an atom can be split. From a group of components, a new composite component can be created, that is to say, components can be merged. Dependencies: Dependency described by link is a type of relationships other than hierarchies. By means of links, the relationship layer of the model can be viewed as a graph. The nodes of the graph are atomic or composite components while the edges are links. A Link can have more than one sources and destinations. Unlike hierarchies, the end of link can be referred to locations within the content of an individual component by means of anchoring. In most cases, the link s endpoints, namely anchors, are some features within the component. The link comprises three parts, input, output and condition. Input and output are ends of the link. They both include one or more specifications, each of which points into a component. Condition is a relationship expression of input and output, some runtime information can be attached in it. The structure of a link is shown in Fig.5. In each specification of output, there is a reactor specifying what to do on the pointed component when condition is not satisfied. Thus the semantic of link can be expressed: if (! condition) trigger all reactors of output as soon as input changes condition For example, in the design of a shaft and a gear, the outer diameter of shaft and the inter diameter of the gear are dependent. The designer of the input output gear can created a link. The parts of the link are: input: d o outer diameter of the shaft Fig.5 Structure of link( the gray output: d i inter diameter of the gear condition: d i d o = 0 boxes stand for link specifications) reactor1: assign d i = d o reactor2: notify the designer of the gear the nonconformance. In most cases, reactor2 is more preferable than reactor1. When the designer of the gear receives the nonconformance report, he or she may prefer negotiation with the designer of the shaft instead of modifying the inter diameter of the gear being modified immediately. (3) Manipulation Layer The manipulation layer is responsible for the interface between the model and the users. It manages the display of the network of components and handles user interactions. This layer has a complete knowledge of runtime information. This layer can give a same component different views, according to state and presentation specification of the component, and some runtime information such as user privileges. To enhance cooperation awareness, this layer synchronously shows participants some information such as what other participants are doing, what occurs on the network. (4) Data Layer The data layer can be divided into two fields, tools field and data field. Data field is the application dependent content which can be managed by the application specified in the tool field. The range of possible content/structure that can be included in a component is not restricted. Text, graphics, animation, images, models, CAD drawings, and many more types of data can be the content. Any type of data can be the content as long as there is a tool that can mange it. A tool takes care of a specific type of data. Data can be embedded in the component, or be stored outside of the content and connected to the component. The content is deeply dependent upon the application the tool field specified. Most of the current single-user applications and their private data models can be integrated in this layer. Although the relationship layer has no knowledge of the content, a link can still point into the content of a component by means of anchoring. The mechanism of anchoring gives a fine grain of link s endpoints. (5) Summary As discussed in the forgoing paragraphs, the three layers of HyCD focus on the structure, data and view of the model, respectively. The separation of common structure of the model and application-dependent data makes it easy to integrate most of current single-user applications, and to exchange data between the model and the outer environment. The separation of structure and

5 their view makes multi-view of the same component possible. By placing application-dependent information in the data-layer, a wide range of hierarchies can be covered by composite component. Although the relationship layer has no knowledge of the application-dependent data, anchoring provides a fine grain to link s endpoint. In summary, HyCD has an open architecture, and many design areas can take advantage of it. In the remainder of this paper, we will focus on the cooperation-support of this model by introducing a cooperative design system based on HyCD. 4. The System Based on HyCD CoDesign, a cooperative design system based on HyCD model, is developed on windows95 platform. It is programmed in Visual C++, and the network protocol used is TCP/IP. It can support cooperative design activities among multi-users distributed over intra-net. (1) Modes of cooperation on HyCD Design and authoring in large design projects involves cooperative work among individuals contributing to the overall design task. Such work involves both explicit communication and coordination, and implicit coordination through shared materials[3]. In cooperative design situations, a number of users are manipulating a large body of artifacts using a variety of tools. We assume that the shared artifacts are modeled by HyCD model. We have identified several modes of cooperation based on shared HyCD networks: Separate responsibilities. Users manipulate different components, and there are no hierarchy or dependency relationship among their components. Users may inspect components manipulated by others. The cooperation here is quite loose and mainly consists of one user making annotations of designs of developed by others.. Hierarchy cooperation. Users manipulate different components, but there are hierarchy relationship among their components. The update operation of users who are manipulating the children components will interfere with the design in the parent component, and users who are manipulating the parent component should be aware of it in time and reload the latest content. Dependency cooperation. Users manipulate different components, but there are dependencies among their components. Changes occur on the link s source will lead the link into nonconformance and trigger reactors, the designer of the destination component will realize the changes and take corresponding actions. Mutual sessions. Two or more designers may work on the same component at the same time(synchronously) with some direct communication channels open. All operations made by each designer are immediately updated the other designers view of the component. A variant of this cooperation mode is having each user make changes that are not immediately committed, but which may be undone without other users seeing them. (2) Architectures Fig.6 shows the architecture of CoDesign, which consists of three elements: tools: Tools are applications that are integrated into CoDesign. Users can manipulate the content of components using these tools. A critical important piece of tools is the tool adapter, which is developed to help the tools to communicate with the user agent. To be smoothly integrated into CoDesign system, most of existing single-user applications need an adapter. The adapter also deals with the anchor, link semantic, and other application-dependent information. user agent: There is one user-agent per user. It is the client of design servers, and the server of the tools adapter. It manages explicit communication, and coordination among users via channels of video, voice and electronic white-board. It distributes notifications which are received from servers and served as a way of implicit coordination among users. It embodies the manipulation layer of HyCD model and provides tools-independent operations on the model. server: It centrally manage a database of component, and a group of files that serve as the storage of application-dependent data. Every event occurs on the shared network can trigger a notification which will be delivered to the relevant parties. User A User B Tool 2 Tool 1 Tool 2 Tool 1 User agent A video, voice chat, whiteboard User agent B Notification server Tool adapter protocol Component database file Fig.6 Architecture of CoDesign.

6 (3) Model implementation for AutoCAD CoDesign has integrated AutoCAD R13C4 as a tool for design. Another 3D design tool is now being integrated. Here we focus on the definition of application-dependent information in the model for AutoCAD. Content of component: the content of a component is an AutoCAD drawing in the format of DWG. anchor: an anchor is a entity, or a attribute of a entity in the AutoCAD database. Semantic of link: link represent the dependency among geometric element in different drawings. Semantic of composite component: the content of a composite component is a main drawing which is composed of several sub drawings stored in child components. The sub drawings are external references in the main drawing and the main drawing have information required to resolve these references. (4) Cooperation support In the area of support for cooperation involved in collaborative use of a shared network, the critical notions are mutual intelligibility and access control. Each participant must have some degree of understanding of the actions and intentions of other collaborators[2]. In CoDesign system, many participants are manipulating a large body of components. Among these participants, there are complicated relationships which are derived from relationships among the components they are manipulating. In order to coordinate the participants activities and enhance cooperative awareness, CoDesign support synchronous channels of communication and coordination, such as video, voice, white-board, chat, as well as notification which coupled closely to the shared network. In order to give designers a save storage of their designs in a shared environment, CDesgin also provides access control for components. Here we focus on the notification support and access control. Notification Notifying relevant parties when certain critical events occurs is an important mechanism for coordinating multi-users activities in a cooperation effort. This notifying should take place as early as possible. Early notifying ensure that collaborative users can detect possible conflicts as early as possible and modify their actions accordingly. Notifying is an automatic mechanism that helps multiple users coordinate their ongoing work in a cooperation[2]. In CoDesign, Any operation that will change the runtime or storage status of the shared network can trigger notifications. The following are some examples of notifications User A has just login to the system May 06 16:30: User B has just updated the gear_10 May 06 16:35: NOTIFICATION: User A has changed outer diameter of the axle in drawing shaft-12, this has something to do with the inter diameter of the gear in your drawing gear_15 May 06 16:30: Notifications are delivered immediately after generated. Normally notifying are triggered by event that have no effect on the storage of the shared network, such as user log-in and log-out. Those operations that have changed the storage of the shared network trigger critical notifications, which must be informed to the related parties, no matter whether they are currently in the system. For example, nonconformance report triggered by changes of link s source, will be saved until the owner of the link s destination explicitly deal with it. Subscription of notifications are supported. User can ask to be informed some events which he cared about, such as specific operations occur on an arbitrary anchor, component or the whole network. Access control In CoDesign, there are three types of user status for a component: Owner: The owner of a component is the designer who creates or initializes it. There is only one owner for a component in the life of it. The owner have the right of modification even deletion of it. Locker: The locker of a component is the designer who currently has the token of modifying the content of it. At one time, a component has no more than one locker, and in most cases, the locker is the owner. A component can have a locker other than the owner only when it is not in the state of invalid. Reader: The reader of a component is the designer who can inspect the content of it. Since readers can not modify the component, the number of readers of a component is not restricted. All eligible users of system can be readers of any component. But a component can have readers only when it is in state of ready, in other words, when the content of it is available for inspection. 5. Application Scenario This section describes a design scenario extracted from a mechanical design. The goal of the design is a drawing shown in Fig.7.

7 The tool used is AutoCAD R13C4. Here we describe the steps which designers will follow: (1) Task division The first step of the cooperation is to decompose the task. CoDesign provides desk-top conferencing facility for this. At the begin, a desk-top conference among all the designers is hold to decide the decomposition of the design artifact. Designers discuss via channels of video, voice, chat and white-board. The process of decomposition is from top to bottom. At last, a hierarchy diagram is drawn and the white-board outputs it into a script file. The script file include specifications of eligible key0 users, primary nodes, rough hierarchies and dependencies within the design object. The drawing shown in Fig.7, the diagram outputted is shown in spacer key1 Fig.8. shaft (2) Model initialization The second step is to input the script file to the server of CoDesign. The server will create a framework of the HyCD model. Then eligible users can log-in the system and follow the steps system prompted to initialize the component they are responsible for. One can create new component to decompose his or her work further. nut gear1 gear0 (3) Design process Fig.7 The main drawing Every component has a color in which it is shown. Upon created, all components are in state of invalid, and shown in red. Designers first create content for atomic components, such as shaft, key0, key1, gear0, gear1, spacer and nut in Fig.8. These components will rise to state of closed and will be show in yellow. Then designers can edit their contents using AutoCAD. When the contents are finished, they will rise to state of ready and the color will change to green. When shaft, key0 and key1 are all in ready, the component axle will rise to state of closed and the color will change to yellow. User A will be aware of the change and realize that the drawing of axle can be composed. Similarly, when axle, gear0, gear1, spacer and nut are all in green, the color of main node will change to yellow, and the main drawing is on work. gear0 gear1 user B user C key0 user B main axle key1 user C user A nut spacer user A user A shaft user A (4) Social interactions Fig.8 The division of main drawing After axle changes to state of ready, any changes occur on drawing of shaft, key0 and key1 will trigger a notification to the owner of axle, user A. User A can ignore it, because the drawing of axle will automatically load the latest version of shaft, key0 and key1. User A can also call the designers who made the changes to negotiate by synchronous channels such as video, voice and white-board. Sometimes, user B want to modify drawing axle which have a reference to drawing key0, he applies the lock on drawing of axle. Granted by user A, he can obtain the lock and modify the drawing of axle. During the design process, user B want the inter diameter of gear0 to follow the outer diameter of shaft, he can create a link from the shaft to gear0, and customizes the reactor of it as change automatically. Then when the outer diameter of shaft changes, the inter diameter of gear0 will change immediately. If user B customizes the reactor as notification, he will be informed with any changes of the outer diameter of shaft. (5) Annotating activities When a drawing is ready, designers other than owner or locker can inspect and make annotations to it. User A is responsible for shaft and axle, he wants to inspect the gear0 or gear1. When the color of gear0 is green, he can open a view of the drawing gear0, and make annotations by using a drawing tool. The annotations are saved in a separate file, but associated with the drawing gear0.

8 6. Conclusion Requirements of a general information model for cooperative design is discussed and an open information model named HyCD is introduced in this paper. To demonstrate the model, the HyCD-based cooperative design system CoDesign is introduced, and an application scenario is also presented. The open architecture is a distinguished feature of HyCD model. Most of current single-user applications can be smoothly integrated into it by the aid of tool adapter. They can work in the data layer even without a adapter or any knowledge of the structure of the model. The model is not monopolized by an application but shared by different applications, and the data within the model, which is intact, can be shared by other applications outside of the model. HyCD provides explicit cooperation support. HyCD describes two types of relationships among components, hierarchies and dependencies, by composite component and link respectively. The relationships among components can also be viewed as cooperation relationships among participants. Composite component can also be used to model the multi-user design process, while link gives participants a flexible way of coordinating their activities. Notifying is an important mechanism of coordination, which is closely coupled to the shared model. Refference [1] Halasz,F.and Schwartz,M. The Dexter hypertext reference model. Communications of ACM, Vol.37(2), Feb.1994, [2] Halasz,F. Reflections on NoteCards: Seven issues for the next generation of hypermedia systems. Communications of ACM, Vol.31(7), July 1988, [3] Gronbaek,K., Hem,J.A., Madsen,O.L. and Sloth,L. Cooperative hypermedia systems: A Dexter-based architecture. Communications of ACM, Vol.37(2), Feb.1994, [4] Gronbaek,K.,Kyng, M., and Mogensen, P. CSCW challenges: Cooperative design in engineering projects. Communications of ACM, Vol.36(6), June 1993,67-77 [5] Michael P Case and Stephen C-Y Lu,Discourse Model for collaborative design, Computer Aided Design, Vol.28(5), 1996, [6] Pippa Hennessy, et al., Distributed work management : activity coordination within the EuroCoOp project. Computer Communications, Vol.15(8), [7] Milad Saad and Mary Lou Maher, Shared understanding in computer-supported collaborative design, Computer Aided Design, Vol.28(3), [8] C.A.Eills, S.J.Gibbs and G.L.Rein, Groupware: Some issues and experiences, Communications of ACM, Vol.34(1), 1991,39-58 [9] Gerhard A. Schloss, Michael J.Wyblatt, Presentation Layer Primitives for the Layered Multimedia Data Model [10] Vinod Anupam, Shastra : Multimedia Collaborative Design Environment. IEEE Multimedia, Summer 1994, [11] Wang Ruidang,et al., Information Models for Building Design System, Proceedings of International Workshop on CSCW in Design, Lin Zongkai and Jean-Paul Barthes Ed.. International Academic Publishers, Beijing, [12] Weiyun Ying, et al., Research on Cooperative Distributed Design, same as [11].