Article written with Isabella Bozza and published at IMS’97, Proceedings of 4th IFAC Workshop on Intelligent Manufacturing Systems, Seoul, Korea, July 1997
Franco Folini and Isabella Bozza
Abstract
The current evolution of software systems supporting the design and production process is gradually extending the domain of “traditional” CAD systems to integrate CAM, CAE, and PDM modules. Consequently, the CAD model is shifting from a geometry-only focus to one that integrates information and data from the entire design and production processes and the entire product life cycle. This heterogeneous information is characterized by a growing network of relations. The data used or produced by designers, draftsmen, production engineers, 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 other relations are completely implicit. The management of these relations is left to the users. Furthermore, software systems offer users different interaction modalities for each relation type, depending on the relation type or the software module involved in the operation. For some types of relations, 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. Based on this framework, it is possible to verify the quality of a CAD system implementation and 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 standards, such as OLE, CORBA, etc., have begun 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 the “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 real-world design and production process. The word “relation” is here used with the most general meaning and refers to all kinds of links between pieces of homogeneous or heterogeneous information, even at different levels of detail. For example, a relation can exist 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’s 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 based on such results. Many relations, even important ones, are hidden or difficult to access by the user. For example, in many CAD modules, it is always difficult or impossible to explore the dependency 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’s point of view, geometry is only one of the many aspects of a mechanical part or product. During the different design tasks, designers and draftsmen are required to take into account 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 for the geometry. In order to offer this level of functionality, current CAD systems use either multiple heterogeneous data structures, integrated and centralized on a workstation, or a single model distributed on a network. In both cases, the model is called the 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 inquiry of geometric data.
The increased variety and quantity of data managed by a typical CAD system imply an exponential growth in 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, version numbering, or explicitly described in technical documentation and reports should now be 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, remain 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 same 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 and editable with homogeneous, simple, and consistent tools. People involved in the design and production processes expect to spend their time and efforts on design problems, not on learning and understanding tools to access the information.
A more homogenous and coherent approach, as suggested in the following paragraphs, can help designers to perform their work and to concentrate on the specific design task instead of losing 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, represent, and 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 to by the software system. Nodes can be either atomic entities no more subdividable into the smallest parts, e.g., a point in a 3D space, or nodes composed of sub-nodes, each of which is referable as a single information element. In the following, nodes are indicated by the lowercase 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, use and model many kinds of relations. It is possible to classify these links on the basis 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 user interface, it is possible to verify that different kinds of relations are referred to with different names; some names are chosen by software developers directly from the designer’s 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 to the local policies rules. It is important for the designer to maintain control over all relations connecting data, software, part libraries, symbol catalogs, 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 expressed 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 user interfaces, 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 a 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 also include the management of relations attributes and state. In many contexts and applications, the state of a relation and its attributes are as important as the relation itself.
This operation corresponds to the ability to navigate through relations following references like in a hypertext and inquiring about relation attributes and linked nodes. In a more advanced use, browsing activity requires the software system to have 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 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 performing 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 measurement of the path length, as the collection of relations connecting two nodes.
Viewing and zooming. This operation translates internal data structures and links in a textual, hypertextual, or graphical form, making it 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 certify the integrity and validity of a set of relations and nodes. Not only is it 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 to 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 applications, it can be of interest to audit and log the use of some relation, in order to identify and 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 purposes. Publishing CAD data is becoming increasingly important in order to make information visible and accessible within the enterprise Intranets or, in some cases, 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 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 into a textual or graphical format. The emerging standards are the HTML language and the standard 3D description language (VRML). The publishing operations must be performed while preserving the existing policies and 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 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 coordinated and uniform approach, able to simplify 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 it 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, supports 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, similar to the tabular representations used in database systems (Fig. 2). This technique is used in many systems and is usually preferred for the visualization of and interaction with data, even in large quantities, 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 systems only for online help. These representations are now also used for other types of information. The diffusion of the 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 supporting a fast and effective diffusion of these techniques. All the main CAD systems on the market now include 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 loses its readability characteristics and becomes unusable. An effective graphical representation of a 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’s language and knowledge. Usually, the graphical representation constitutes a near-complete set of operations 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 also becoming more frequently used in design systems. The hierarchical representation of tree structure is simple to use and easy to read. The “expand” and “collapse” operations provide the user with 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 that follow 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 to access all the information represented in 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.
