Article written with Isabella Bozza and published at IMS’97, Proceedings of 4th IFAC Workshop on Intelligent Manufacturing Systems, Soul Korea, July 1997, page 441-446.
Abstract
The current evolution of software systems supporting the design and production process is gradually extending the “traditional” CAD systems domain to integrate CAM, CAE and PDM modules. Consequently, the CAD model is changing from a geometry-only nature, to integrate also information and data from the whole design and production processes and from all the product life. This heterogeneous information is characterized by a growing network of relations. The data used or produced by designers, draftsman, production engineer and other experts involved in the design and production process is connected by many types of relations. Some relations are represented explicitly in the integrated CAD model while others relations are completely implicit. The management of these relations is left to the users. Furthermore, software systems offer to the users different interaction modalities for each type of relations, depending from the type of relation or from the software module involved in the operation. For some types of relation, many CAD systems offer only a limited set of operations. This paper proposes a classification of different types of relations and suggests a basic set of operations on them. On the bases of this framework, it is possible to verify the quality of a CAD system implementation and to adopt a more systematic and uniform approach to the problem.
1. INTRODUCTION
The software systems currently used by engineers for designing the product and the production process are the result of a long evolution. Up till now, the product design was supported by a set of different systems, such as CAD, CAM, CAE, etc. typically connected by means of explicit data conversion and exchange. Nowadays, the market provides for new integrated systems, able to cover almost all the phases of the design process: conceptual design, modeling, structural analysis, assembly, simulation, etc. Besides, new powerful integration technologies and standard, such as OLE, CORBA, etc., begin to appear. A pool of strongly integrated software modules, supplied by one or more vendors constitutes a typical advanced configuration. Each module is designed to support a specific activity and relies on a shared database, usually called “master model”. The advantages of this approach are evident: no data conversion between modules, reduced consistency problems, coexistence of specific models of the product, uniform access to the data, better support for workgroups, etc. For example, engineers performing structural analysis can perform dimensional optimizations operating on the geometry of the part directly in the FEM/FEA module. The use of a shared database allows for a better parallelization of the activities, as indicated by “concurrent engineering” principles. The master model, therefore, is a big container that collects and organizes heterogeneous information about the product, its functional and physical properties, its production process and its life cycle. Within the master model, a network of links exists to represent dependencies and relations between models, versions, components, etc.; these links are only a fraction of the huge set of relations involved in a realworld design and production process. The word “relation” is here used with the most general meaning and refers to all the kind of links between pieces of homogeneous or heterogeneous information, even at different levels of detail. For example, a relation can exists between two planes defined to be parallel by the geometric modeling module; a relation can connect a component in a library with an assembly that uses that component; a relation links two versions of the same technical report. Many relations, defined or generated during the design process, are not explicitly represented in the master model; in particular, relations between information from different tasks are frequently left to the user responsibility. For example, no relation is usually created to describe the link between the graphical results coming from a finite elements analysis post-processing and a thickness value that has been set on the base of such results. Many relations, even important, are hidden, or difficult to access by the user. For example, in many CAD modules, it is always difficult or impossible at all, to explore the dependencies structure of a complex parametric model. Furthermore, basic operations on relations are presented, in each module of the integrated software system, with different interaction modalities. Such differences do not always depend only on the context lexicon and can confuse the user, increasing the design time.
1. THE PROBLEM
The geometry has always been the main topic of interest for researchers and developers in the mechanical CAD area. From the designer point of view, geometry is only one of the many aspects of a mechanical part or product. During the different design tasks, designers and draftsman are required to take into account also many non-geometric aspects and information. In order to satisfy these needs, computer aided design systems are gradually evolving toward a more complete and general representation of parts and products. These systems are able to model new data types and offer new commands to manage nongeometric aspects of the product and information on the design and production process. All this information is now part of the integrated CAD model as for the geometry. In order to offer this level of functionality current CAD systems use either multiples heterogeneous data structures, integrated and centralized on a workstation or a single model distributed on a network. In both the cases the model is called master model. This model represents the process and product data and, typically, is strongly connected by multiple relations at different levels of detail. Within the master model, relations can connect information items locally to a single data structure, such as in a parametric representation, or globally between different data structures, i.e. the relation between two different versions of the same project.
Today design systems provide a wide and effective user support for every user operation on the geometry; just about all CAD systems have a consistent and effective user interface and a well defined set of operations for the definition, editing and inquire of geometric data.
The increased variety and quantity of data managed by a typical CAD system imply an exponential grown of the number of relations to be managed by the system. Furthermore, many relations previously non-automatically managed in the design process and implicitly represented by identification code, versions numbering or explicitly described in technical documentation and reports should now be represented by managed by means of the CAD and PDM systems.
Despite the new evolutions and enhancements, important components of the CAD system, such as the user interaction techniques and tools remains mainly geometry oriented and therefore inadequate for the interaction with these new types of data. The more evident anomalies of the user-interface are in the management and interaction with the relations of the model. The user interface aspects and behavior, and the set of operations proposed for the interaction with relations are less mature and homogeneous than the corresponding interface elements for the interaction with the geometry. Often, similar relations require the use of different interaction tools, depending on the current design phase, on the geometric context or on the software module used. In order to perform the some operation on different data, the user should learn and use different commands and interaction modalities, while their expectations are for software systems where all the information is accessible end editable with homogeneous, simple and consistent tools. Peoples involved in the design and production processes expect to spend their time and efforts on design problems not in learning and understanding tools to access to the information.
A more homogenous and coherent approach, as suggested in the following paragraphs, can help designer to perform her work and to concentrate on the specific design task instead of loosing time working with software idiosyncrasies.
2. RELATIONS CLASSIFICATION
In order to analyze and describe the state of the art for the representation, modeling and interaction with relations in the current CAD/CAM/CAE systems a minimal glossary is required.
Software system: A program able to manage, to represent and to store information. Software systems relevant to this paper are DBMS, CAD, CAM, CAE, PDM systems, etc. In the following, the symbol 
Node: A basic information element of a model that can be referred by the software system. Nodes can be either atomic entities no more subdividable in smallest parts, e.g. a point in a 3D space, or nodes composed by sub nodes, each one referable as a single information element. In the following, nodes are indicated by the lower case letters a, b, etc.
Relation: A link between two nodes, representing some kind of relationship existing, at the semantic level, between the two information elements. Relations can be explicitly represented, such as hyperlinks in an HTML page, or implicitly represented such as for two different orthographic projections in a 2D CAD model, connected only by relative planar positions. In the following, relations will be indicated by upper case letters. For example 
Software systems, used in the design process, uses and models many kinds of relations. It is possible to classify these links on the base of many criteria. The proposed classification is based on the meaning of relations, taking into account the typical requirements and problems of a general CAD/CAM system and data structure.
The target of the following taxonomy is not to provide a general list of categories but to propose a lexical base for discussions on computer aided design tools and models. The proposed categories of relations are:
One-way constraint relation It is a binary relation
Two-ways constraints relation It is a binary relation
Attachment relation It is a hierarchical binary relation
Sequence relation It is a binary relation
Part-of relation It is a binary relation
Reference relation It is a binary relation
Relations of each type are used and generated in each phase of the design process to connect whole models or single numerical data. Analyzing a software system userinterface, it is possible to verify that different kind of relations are referred with different names; some names are chosen by software developers directly from the designer technical language or within the specific lexicon of the application context, other names are mathematical terms or come from implementation details. These discrepancies can make the software system harder to learn and to use for users.
3. OPERATIONS ON RELATIONS
During the design process, designers produce, correlate, organize and collect a huge quantity of digital information. All this information is stored in a form that can vary from a strongly structured set of data, managed by a well integrated set of software systems, to a group of heterogeneous data produced by different software systems and located on different computers. In all these cases, many relations exist over the data used and produced by the designer during his activities. All these relations should be visible, accessible and manageable by the designer, within the model consistency rules and according the local policies rules. It is important, for the designer, to maintain the control over all relations connecting data, software, part libraries, symbol catalogues, versions, etc. Therefore, the software system should support at least a minimal set of basic operations on every kind of relation.
It is possible to identify a set of basic operations on relations covering all the designers needs. These operations should be chosen so that a complex operation on relations can be express as a sequence of them. Analyzing the existing software systems, it is possible to identify these basic operations. They are called with different names in each context and implemented with different userinterfaces, with relevant differences on every software system and for every relation type. Performing this analysis for the design context, we identify the following set of operations:
Editing This operation groups the basic activities on relations, such as creation, modification end deletion of relations. As for any other type of information stored in computer system these activities should be controlled by a set of rules, context dependent, in order to preserve the integrity and meaning of the overall structure and to respect security policies. Under the “editing” label, we include also the management of relations attributes and state. In many contexts and applications, the state of a relation and their attributes are as important as the relation itself. Esempio
Browsing This operation correspond to the ability to navigate throw relations following references like in a hypertext and inquiring relations attributes and linked nodes. In a more advanced use, browsing activity require, to the software system, the capability to evaluate and display the exact or estimated sensitivity area for a given node or relation. The sensitivity area of a given node a is defined as the set of nodes and relations that are affected by a change to the node a. In many design activities, it is fundamental to have an exact or estimated map for the impact of a modification to a node or to a relation before to perform the change. Therefore the software system should be able to generate such map starting from an entity, following outgoing relations, according their orientation, and selecting the reached entities according a given set of rules. The results should then be reported to the user in a graphical or textual description, human readable. Another activity classified in the browsing operation is the measuring of the path length, as collection of relations connecting two nodes.
Viewing and zooming. This operation translates internal data structures and links in a textual, hypertextual or graphical form, human readable. In order to be useful, the simple viewing of a relational structure has to be enhanced with zooming functions. This implies activities like detailing, abstracting and filtering. Even in this operation, the behavior should be driven by a set of rules defined for the specific context and aligned with the existing security policies.
Validating This operation applies a set of general and/or context-specific rules in order to assert and certificate the integrity and validity of a set of relations and nodes. Not only it is important to check for dangling links, but also to apply syntactic and semantic rules in order to verify the type and the state of nodes referred by relations. In many contexts it is also important to monitor vital or strategic relations in order to ensure the validity of the general structure. Furthermore, for some application can be of interest to audit and log the use of some relation, in order to identify and to document “who”, “when” and “how” data in the model are used.
Publishing: This operation made available a set of relations and nodes outside of the software system mainly for documentation purpose. Publishing CAD data is becoming increasingly important in order to make information visible and accessible within of the enterprise Intranets or, in some case, for the whole Internet. The traditional publishing tools, designed to produce technical documentation and reports to be distributed in digital or printed format, are now being replaced by a new generation of software tools able, on request, to extract the required information and publish it in real-time. These tools are mainly oriented to the digital formats and are intended to support the network access. This approach definitively solves the old problem of consistency between the original model and the data available to the reader of the publication. In this operation, the information, relations and nodes, are converted statically or dynamically on a textual or a graphical format. The emerging standards are the HTML language and the standard 3D description language (VRML). The publishing operations must be performed preserving the existing policies rules defined in the publishing organization.
4. INTERACTION WITH RELATIONS
As previously highlighted, software systems currently available to users in the design area offer partial and inappropriate tools for the interaction and the management of relations. In general, these interaction tools are heterogeneous and insufficient in order to satisfy the users needs.
The growing complexity level of the new integrated design systems requires a more coordinate and uniform approach, able to simplify the access to the information through relations.
Current design systems use a mix of interaction techniques, the most frequently used are:
Properties box: It is a simple window describing an entity, a node in our lexicon, or a relation (Fig. 1). The main purpose of the “Properties box” is to display information about a node or about a relation, no other operations are usually supported.
Even if can be considered the simplest operation on data, when available, it is frequently implemented by hidden or complex commands. The emerging standard is the “Properties tabbed window” proposed by Microsoft Windows. This presentation technique allows a simple and direct access to all the information describing the node and to all its attributes and, in many cases support also some modification to the node and to the relation connected to that node.
Tabular description: This representation shows a list of nodes and relations in a table similarly to the tabular representations used in databases systems (Fig. 2). This technique is used in many systems and is usually preferred for the visualization of and interaction with data, even in big quantity, that is homogeneous and well structured. The B.O.M., Bill of Materials, is a typical example of a tabular description automatically produced by a CAD system.
Hypertextual description: Traditionally, hypertextual descriptions were used by software system only for online helps. These representations are now used also for other types of information. The diffusion of Internet and of its standards, such as the HTML and VRML languages, is suggesting new and more powerful ways to use these techniques. Furthermore, the recent diffusion of Intranet and Intranet servers, now easily connectable to a database, is now supporting a fast and effective diffusion of these techniques. All the main CAD systems on the market include now a converter to the VRML format.
Graphical descriptions: It is a graphical representation, usually a planar graph, of a set of nodes and relations. Many research activities have been done in recent years on the graph visualization problem (Di Battista, et al., 1994) but, from the CAD perspective, the problem is still open. When the complexity of the structure is more than trivial, the graphical description looses its readability characteristics and become unusable. An effective graphical representation of complex structure can be obtained only for hierarchical structures (trees) or for graphs strongly structured in subgraphs. The graphical description is usually proposed as the representation most close to the designer language and knowledge. Usually the graphical representation constitutes the preferred a near complete set of operation on relations and nodes.
Hierarchical graphical description: This is a mixed textual and graphical description used for hierarchical structures, such as trees. These descriptions, proposed by the Macintosh and the Windows operating systems for user interaction with the file systems, are becoming more frequently used also in design systems. The hierarchical representation of tree structure is simple to use and easy to read. The “expand” and “collapse” operations provide to the user the required level of flexibility and constitute a good example of the zoom operation. The main limit of these presentation techniques is the inability to display nonhierarchical structures.
6. CONCLUSIONS
Software systems following these guidelines will constitute a true integrated environment of specialized modules, rather than a chain of connected systems, and will provide the user with the ability of accessing to all the information represented within the “master model”.
7. REFERENCES
Harary, F. (1969). Graph theory, Addison Wesley, Reading, MA.
Di Battista, G., P. Eades, R. Tamassia and Tollis I.G. (1994). Algorithms for drawing graphs: an annotated bibliography. Computational Geometry, Volume 4, pp. 235282.Gansner, E.R. (1993), A Technique for Drawing Direct Graphs, IEEE Transactions on Software Engineering, Volume 19 No. 3, pp. 214230.
Franco Folini 