proprietary software written by the end user/s). They will run under ..... process, pros and cons for each alternative and the rationale for the selection made are ...
Proceedings of The 1996 ASME Design Engineering Technical Conferences and Computers in Engineering Conference August 18-22, 1996, Irvine, California
96-DETC/EIM-1420 INTEGRATION INFRASTRUCTURE TO SUPPORT CONCURRENCE AND COLLABORATION IN ENGINEERING DESIGN Plamen I. Bliznakov Department of Mechanical and Aerospace Engineering Arizona State University Tempe, Arizona 85287-5406
Jami J. Shah Department of Mechanical and Aerospace Engineering Arizona State University Tempe, Arizona 85287-5406
Susan D. Urban Department of Computer Science and Engineering Arizona State University Tempe, Arizona 85287-5406 ABSTRACT Traditionally, CAD tools have provided limited possibilities for interaction between different participants in a design project. This paper describes an environment for information integration of CAD systems and other application programs referred to as meta-level design information system. Taxonomies of CAD and other application programs with regards to their "integration friendliness" and possibilities for remote access by the enduser are developed. These taxonomies can be used by CAD vendors as a guidance for development of software which can be integrated easier in a higher-level design information system. In this work the taxonomies are used to catalogue the applications and their data. The information integration infrastructure is based on an object-oriented multidatabase using the WWW to transfer the transactions. An information broker provides a global conceptual view of data and knowledge stored in a metadatabase including description of product data and design constraints, design process, organizational information, etc. It processes user queries and dynamically accesses the information from CAD tools (which act as objects on the WWW) if needed. The CAD tools interface is provided by software network adapters. They export parts of the local application models needed for maintaining intertool constraints and supporting remote queries by
participants in the design process who do not have direct access to the CAD systems. NOMENCLATURE API - Application Program Interface CORBA - Common Object Request Broker Architecture DIS - Design Information System EDM - Engineering Document Management OODBI - Object-oriented Database Interface PDM - Product Data Management RAM - Random Access Memory SDAI - Standard Data Access Interface SNA - Software Network Adapter UI - User Interface URL - Uniform Record Locator WWW - World-wide Web Put body of the paper here. Put body of the paper here. Put body of the paper here. Put body of the paper here. Put body of the paper here. Put body of the paper here. Put body of the paper here. Put body of the paper here. Put body of the paper here. Put body of the paper here. Put body of the paper here. Put body of the paper here. INTRODUCTION Originally, CAD tools have assumed an interaction with a single user. Gradually, the multi-user capabilities were utilized to allow access to CAD systems by different designers. Nevertheless, the level of cooperation of different CAD users remained relatively low. The exchange of
1
Copyright © 1996 by ASME
information between different CAD systems was also limited, typically, to static file transfer. With the advent of the concepts of concurrent engineering, cooperative and collaborative design, and enterprise system-level design and coordination, the need to exchange information and knowledge dynamically throughout the design cycle increased. PDM systems allow to check-in CAD data files into server databases, index them, check them out, associate those files with certain design activities, and thus facilitate searching and distributing the files among multiple participants in a design project. Nevertheless, the PDM systems simply add another application model which is not really integrated with other application models. They do not allow dynamic access to data from different models for such purposes as maintaining constraints across these models or dynamically distributing data of concern to designers who do not interact directly with a given CAD tool. The new possibilities for dynamic data, software (and, more generally, service) sharing in the heterogeneous environment of the Internet allow to overcome many problems which CAD users currently face in a collaborative design environment. This work summarizes the authors' experience and results to develop a distributed, heterogeneous, active engineering DIS. Earlier results of this research were reported in [Bliznakov95a, Bliznakov95b, Jeon95, Shah96, Urban94, and Shah93].
example, many of the interactions between the actors in the design process. In addition, while the objective was to support routine mechanical design to the highest degree, to be practical, the implemented DIS had to serve at least to some extent cases of novel and evolutionary design as well as design in related domains (e.g., electromechanical, electrical). The reason for this is that a typical engineering problem transcends class boundaries and involves more than one class. The following assumptions were made: • The software and hardware environments are heterogeneous and distributed. This means that, in general, the software programs will be supplied by different vendors (some of them - possibly, proprietary software written by the end user/s). They will run under different operating systems (most often, different flavors of UNIX, MSWindows, Mac OS, VAX/VMS, MS-DOS, etc.) on different computers connected by a computer network. The latter is assumed to be TCP/IPcompatible. This is a reasonable assumption as, first, the majority of public and corporate global networks and most popular brands of local networks have nowadays gateways to the Internet. Second, the most popular operating systems mentioned above have TCP/IP protocol functionality either built in into their core or available through additional software. • As a design develops, there are often conflicting ideas proposed by different individuals or teams because of their different viewpoints (design vs. manufacturing, for example). It should be possible for such conflicting data to co-exist until a compromise is made.
2. PROBLEM DEFINITION AND SCOPE The objectives of this work included development of a DIS at a higher (meta) level with regards to the different application (CAD and other) systems. The purpose of this meta-level DIS was to eventually: • provide answers to queries of various participants in the engineering design process whenever they cannot obtain those answers for one reason or another directly from application programs • facilitate integration of various application tools in terms of exchange of data, maintaining constraints and propagation of changes through different application models, and providing services by some application modules to others This research originally focused on the cases of routine mechanical engineering design which included matching design and configuration synthesis. The former involves "sizing up" a system or device to the desired conditions. In matching design, the function, shape, and form of the artifact is well known. The latter involves the synthesis of desired systems using well-known existing components whose behavior can be modeled as "black boxes" [Shah89]. Routine design, however, does not imply fixed or algorithmic procedures. It only means that the methodology is well known and widely accepted. Originally, the scope of this research was also limited to a single designer case. In the process of the research, however, it became obvious that some of the major benefits of a meta-level DIS can be obtained only in the multiple designer case. That meant that the implemented DIS had to represent, for
3. INTEGRATION OF DESIGN AUTOMATION SYSTEMS During the recent decade or so there has been significant interest both in industry and academia in extending the scope of design automation tools from specific applications to enterprise-wide integrated systems. The initial efforts attempted to extend drafting systems and 3D geometric modelers by adding closely-coupled application modules (e.g., for NC programming) which would utilize the geometry already in the CAD database. SDRC offered one of the first integrated solutions by linking such applications as geometric modeling, mechanism modeling, drafting, and finite element modeling (originally developed by different vendors) through a common database [Batanov84]. This database further evolved to allow end-user programming access. The scope of applications being integrated also grew and still grows from modules to create and manipulate different aspects of the product model to design process recording. For example, many CAD systems allow recording of user sessions which later can be used for automating the modeling procedure with a different set of input parameter values. Along a separate line, project planning applications are used for workflow modeling of design projects, while
2
Copyright © 1996 by ASME
manufacturing operations are planned and reported using process planning and other related software packages. Many CAD packages allowed programming interface to their core routines (e.g., for database access, geometric modeling, and user interface management) through function library calls or proprietary programming languages. Eventually, such "open architecture CAD tools" became the major product of companies like Spatial Technology [ACIS95]. This trend which progressed from data sharing to routine sharing, however, is largely limited within the CAD system developed by a single vendor, licensed by that vendor from external developers, or closely coupled with this vendor's core software package. Along a parallel trend the standardization bodies tried to provide data and function sharing among different CAD tools. Several versions of IGES [IGES88] allowed exchange of (mostly geometric, drafting, and finite element) CAD models among various CAD systems. The effort was continued by PDES/STEP which tries to comprehend a broader scope of models. EXPRESS is used to define various application models. The intention is for STEP to eventually allow not only exchange of models through static files, but dynamic access to common databases through the SDAI [ISO93]. SDAI is a low-level interface that supports creation, retrieval, modification, and deletion of data using the object-oriented views provided by STEP. Mappings from STEP models defined in EXPRESS onto four DDLs including a relational data model (ORACLE) and three object-oriented ones (OpenODB, Versant, and ObjectStore) are described and analyzed in [Hardwick95]. Data was transferred either through an upload/download interface or through direct SDAI bindings. While the CAM-I sponsored effort to standardize geometric modeling functions in AIS [CAM-I90] did not gain a broad acceptance among software vendors, it somewhat influenced development of "open architecture" toolkits like ACIS. The traditional CAD systems made limited use of capabilities of computer networks for information and knowledge sharing among multiple users. A typical CAD system is located (along with its database) and running on a single computer. The users can start the software from their workstations. The interactions between the users themselves are limited typically to sequential access to common model files with access control delegated to the underlying operating system. Simultaneous work on a single model from different workstations so far has been limited to conference mode freehand graphics interaction (typically accompanying teleconferencing). In addition, the computational load is not as distributed among different computers as it could be even though modern workstations and personal computers offer substantial processing power. The research in engineering database development aimed at overcoming some of these shortcomings started back in early 1980s with such works as the ones published in [Encarnacao82]. Examples of database environments in support of engineering design include the PRIMA/MAD project [Hubel92, Harder87], AREDAS [Vossen88], the 3DIS
system for VLSI design [Afsarmanesh85, Granacki85], etc. None of these systems, however, addresses the issues of interoperability with CAD tools. The distributed heterogeneous character of engineering design data is addressed by Magleby and Gunn [Magleby92]. There software, Cimphony, provides Information Services Exchange to serve as an object request broker between CAD tools acting like agents. Each object maintains its own data model, no global conceptual view is provided. Objects are responsible to decide what services they need from other applications. They communicate with each other by sending requests. Standard UNIX interprocess interface is used for communication. New agents can be added to the environment without changes to the software and recompilation. Constraints can conceivably be imposed by an application on a model, but an overall mechanism to address constraint management is not provided. A hybrid hierarchical scheme for information exchange between mechanical and electrical CAD tools called Distributed Relevant Data Exchange Approach is proposed in [Wang95]. The information exchange within a single domain (e.g., mechanical) through a common database is envisioned. The authors further propose to exchange only the relevant data between mechanical and electrical domains through common neutral format files and a global database manager. The approach makes the information exchange more manageable. In addition, the approach is extensible and reduces the data communication. The dynamics of the data access and exchange is limited as the data transfer between domains needs to be initiated by the user. The work also does not aim at maintaining general design constraints across application models besides maintaining the consistent correspondence among the design data. Two research systems - ROSE [Hardwick89] and EMTRIS [Rangan91] utilize relational technology on lower level for faster indexing and retrieval and object-oriented techniques to describe the structure of the objects. For example, EMTRIS (Engineering and Manufacturing Technical Relational System) uses ORACLE to help engineers locate and retrieve design information. Most of the research in engineering data management mentioned above also concentrates on only one (although probably the most important one) aspect of the designrelated data and knowledge: the product data. Additional problems for the comprehensive design information representation arise from the lack of adequate project history models. These design histories can be used, for example, to track ongoing projects and to re-use old designs. The data and knowledge which needs to be captured includes different versions (including obsolete ones) of product models related to a representation of design activities, decisions made, rationale, etc. As an outgrowth of the research in engineering data management, commercial EDM/PDM systems appeared in recent years. They try to overcome the shortcomings of the traditional CAD computing environment and to improve the information sharing in large enterprises. Typical functions of
3
Copyright © 1996 by ASME
EDM/PDM systems include "check-in" of a file ( CAD model, text document, raster image, etc.) into a common database for others to "check-out". Files can be indexed by various attributes (e.g., by owner/author, department, creation date, etc.) and later located by specifying search values for those parameters. In addition, files can be organized in hierarchies corresponding to the product structure so that they can be located by browsing. A paradigm of electronic "folders" where users can "put" files and which can be passed from one user to another was pioneered in Hewlett-Packard’s WorkManager. EDM/PDM systems are typically built using the client-
but more often through a human user) data in a different application model. More advanced (in terms of "integration friendliness") applications allow automated access to their functions by other software programs (i.e., the former applications provide a service to the latter programs). The levels of "integration friendliness" are shown in table 1. The applications of level 0 provide minimum possibilities of integration with other programs. Their functionality is available only through some kind of humancomputer interface (e.g., graphical, textual, etc.). Data exchange between such applications and other programs can be performed only through re-entering the information by a human user. In this process s/he can re-enter all relevant aspects of the application model. The process, however, is prone to human errors and is time consuming. Such a limited possibility for data exchange with other CAD systems can be encountered in cases of some custom-written proprietary programs, but is rare if ever observed in commercial applications. The applications at level 1 allow export of data (typically stored in a proprietary work format) into a file with known format. The latter file format can be standardized formally (e.g., IGES or STEP) or be a de facto standard (e.g., DXF). Although a human user still might need to be involved in the information exchange cycle (e.g., to invoke the export command through the user interface), this action is routine and consumes little time. The neutral files can further be exchanged between computers running application network programs (e.g., ftp). One of the shortcomings of this mode of data exchange is poor selectiveness (typically, whole models are exported regardless of the particular needs). Additional modules might be needed to filter out only the required information. Another disadvantage is the unavoidable information loss, as the neutral data model is normally an intersection of the application models of software packages of a certain class. For example, formats for geometric model exchange (e.g., respective parts of IGES and STEP) at present do not allow to represent the geometric constraints used by the user to define a model, even though most of the CAD packages store this information in their proprietary application databases. Lastly, some misinterpretations built into the preand post-processors can lead to inaccuracies in the data exchange through neutral files. This type of information exchange is typically available in the vast majority of commercial CAD systems. The applications at level 2 allow some automated access to both their internal data and functionality. The data exchange between programs running on a single computer again is typically performed through files (and more rarely, as command line parameters or "mailboxes" in the computer RAM). Those files, however, can be generated by running a procedure in a proprietary (specific for the application software) language in batch mode by operating system calls. The procedure can be written at the time of the DIS set-up (if the specific queries are known in advance) or dynamically generated by a translator from the query language of the DIS onto the proprietary programming
Table 1. Taxonomy of application software according to its "integration friendliness". Level Access to application data and functionality by other programs 0 Through a human-computer interface only 1 Through neutral exchange data files (e.g., files in IGES or STEP formats) 2 Through proprietary language procedures in batch mode 3 Through API (high-level programming language) function calls 4 Through object method calls on a local computer 5 Through object method calls over a computer network server architecture, where shareable files are stored on computers-server. Some of those systems require a specific underlying DBMS, while others allow the end-users to chose one of several options. The relational DBMS technology, however, dominates in this field even though the end-users are typically given an object-oriented view of the data. An important shortcoming of PDM systems at this point is the lack of a genuine integration and merging between different application models. In practice, PDM systems add another application model which might include remote file names and the CAD tools used for their creation and manipulation as attributes. To solve such problems as maintaining constraints across different application models (inter-system constraints) at least parts of these models need to be exported and integrated into CAD multidatabases. 4. INTEGRATION “FRIENDLINESS” Integrating existing CAD and other application software was one of the major objective of this work. For that reason it was important to identify different levels of "integration friendliness" and consider the possibilities for integration of different applications with each other and with the DIS in each particular case. Integrating different applications means at least allowing those applications to exchange parts of their respective application models. In particular, the meta-level DIS can be retrieving part of the application models data in order to verify certain constraints. As a result of this verification, DIS might need to modify (possibly, directly,
4
Copyright © 1996 by ASME
language. The application software functionality (e.g., determining mass properties for a geometric model of a part) is available to external applications through same procedures (although some part of the application functionality might not be available in this mode). A minor disadvantage of this type of integration is its somewhat lower dynamics (compared with the case at level 3), since the exchange data captures a snapshot of the application model at the time of the execution of the batch procedure. This type of access to individual application models is available in many larger and well-established CAD systems (for some of them the proprietary languages are part of their legacy user interfaces from the pre-graphical user interface era). The application programs at level 3 provide access to their database and/or functionality through an API interface. This means, that DIS can have components running on a local
functionality of the application programs does not have to be replicated in the meta-level DIS. The issue in this case is how to provide remote (typically, over the network) access to the application programs by end-users. Each application program can be subdivided into the following four layers: user interface, application modules, application model access functions, and application data. The user interface module manages the human-computer interaction by allowing the user to specify commands and parameters. It invokes respective application modules as requested by the user. The application modules implement the application’s functionality and access the application model data through corresponding access modules. In general, each of these four layers can be located on a different node on a computer network (i.e., the network can be placed between each pair of these four layers). In addition, the modules of each of these layers can be stored locally at the computer on which they are executed, run remotely (client-server architecture), or downloaded from a remote location to the local computer for execution as needed (mobile computing paradigm). The latter approach is gaining Table 2. Taxonomy of application software according to the possibilities for remote user access (with examples). Modules\Acces a. Local b. Remote c. Mobile s (Downloaded ) I. User Mac or X-WindowUser Interface MSbased interface Windows application Java applets application with exported s DISPLAY II. Application Local Remote Java applets Modules application objects (e.g., performing Server-side application WWW functions scripts) III. Application Local Distributed Java applets Data database database accessing Access access server local or Modules functions functions remote data IV. Application Data on a Data on an An image Data local disk NFS-mounted file disk downloaded on the WWW popularity recently with the development of mobile computing languages like Java [Gosling95] and JavaScript [JavaScript95] not pertaining only (strictly speaking), but used mostly on the WWW (which provides various ways to access data and programs). The CAD systems due to their specifics (large and expensive software systems in which the application modules are tightly coupled with the user interaction and which have complex data models) typically provide limited possibilities for remote user access. Most often, these would be limited to categories Ib and IVb. The mobile computing paradigm is relatively new. Even though it offers very
computer which are linked to the API functions. These components can reply to queries and the instantaneous state of the application model can be reflected in the replies. More interestingly, the components could continuously monitor the state of the application model and can trigger reports to the meta-level DIS themselves. Data access through API calls is usually offered as an option for CAD systems which would allow development of some customwritten modules (often, the functionality of such interfaces is limited). Some "open architecture" toolkits provide API interfaces as the only means to access their functionality. With the advent of the object-oriented technology application programs can be accessed as objects. This objects can exchange information through a common "clipboard" in the memory of a local computer ( level 4) or over a computer network ( level 5). The former is provided by such operating systems as Mac OS and MS-Windows, while a mechanism for the latter is specified by CORBA [CORBA95]. Such possibilities for data exchange with commercial CAD systems are still rear. Making CAD systems available as objects on a wide area (or global) computer network represents a challenging paradigm shift. Some software applications provide mixed possibilities for integration. For example, retrieving information from a CAD database can be available through an API interface (level 3), but recording information into this database might be available only through a human-computer interface (level 0). 5. POSSIBILITIES FOR REMOTE ACCESS TO DESIGN AUTOMATION SYSTEMS BY END-USERS Another objective in the development of the meta-level DIS was to provide answers to queries by various participants in the design process. Part of the queries can be answered based on a single application model. Such queries are best answered directly by the individual application programs themselves. The reasons for that are, first, that each application software can most fully utilize its own proprietary application model and the latter does not need to be exported to the common global database. Second, the
5
Copyright © 1996 by ASME
development). Alternatively, these could be domains of limited interest (e.g., single industry or even company). • Some of the data in the companies will remain in a non-electronic form: paper reports, hardcopy plots, microfiche, paper manuals, etc. Identifying a structured data model for all of the design-related data in an organization would be a Sisyphus task. It was decided to selectively limit the shared data. The data which have to be exported from the local application models to the global view provided by the DIS need to include only the following (figure 2): 1. data from different CAD/CAM/CAE and other tools related to each other (e.g., data needed to maintain design constraints across different application models, i.e., inter-tool constraints, and propagate changes during a project) 2. data which have to be shared among different groups of designers / engineers / managers who for one reason or another do not have access to the CAD or other software used originally to create the data; this includes data sharing within a single design project or throughout multiple projects (design reuse) 3. data needed in the design process but not provided by any specific application model It is also convenient to use the meta-level DIS as a repository of "BLOBs" - application model files associated with various entities (e.g., product components or design subprojects). Those archived files could be retrieved when needed and further processed by the specific application software. Better yet, the software itself could be either portable and downloadable from the database along with the data, or it can be available as a cataloged service on the network. In cases when more than one software tool use the same model (e.g., a geometric model) and they exchange the data through a neutral format file (e.g., in STEP format), those files can be archived as "BLOBs" as well. Still, the DIS needs to "have a knowledge" about those files content only if data will be interrogated directly through that system, or they need to be related to data from a different model. It must be noted, that the principles for selecting the shared data apply not only to product description information used by different CAD tools. They also apply to design process data which might be created through project planning tools, personnel and purchasing information which might be stored in traditional enterprise business databases, etc. Similarly, infrastructure issues related to the integration of different application tools, dynamic access to application data, user access to the tools, etc. are equally well related to CAD tools operating on the product data, as they are to other application software. From this viewpoint, it makes sense to view all the design-related data and software in a coherent way. Since much of the data available in a DIS will be created and manipulated through individual design automation systems, its database would represent a looselycoupled heterogeneous distributed multi-database. Due to
interesting new possibilities, making their expensive software broadly available in source code (e.g., in the case of JavaScript) or in a form which can easily be "reverse engineered" (as is the present situation with Java) is something the CAD vendors will doubtfully rush towards. 6. INTEGRATED DATA MODEL The work on the development of the DIS started with an intention to come up with an all-inclusive data model which would be a superset of various models used by the integrated application plus the additional information (e.g., constraints relating data from different application models) (figure 1). Such an integrated model assumes that individual application data models in full will be exported. The intention was to use STEP product data models defined in EXPRESS and further extended to represent engineering design histories. In the process of this work the view above shifted. The major reasons for that are the following: • The meta-level DIS does not need to and, moreover, cannot replicate neither all the data (e.g., complete geometric, feature, finite element, design history, etc. models) nor all the Inter-tool Constraint 1
Application Application Model Model 11
Application Model 2
Application Model 3
Inter-tool Constraint 2
Figure 1. An all-inclusive global conceptual view of design data. Inter-tool Constraint 1
Application Model Model 11 Application
Application Model 2
Application Model 3
Inter-tool Constraint 2
Figure 2. Selective global conceptual view of design data. methods (e.g., methods to evaluate stresses) available through individual CAD and other related applications. STEP provides to some extent a minimum common denominator for CAD data exchange. However, individual CAD and other application tools typically have additional proprietary data not explicitly provided by the CAD vendors, which helps support greater functionality, higher efficiency, or both (see the shortcomings of the data exchange through neutral files in section 4). • There always will be specific application model domains not covered by STEP (or another standard). These could be new and developing fields or paradigms within existing fields (standards are only able to follow, not lead the application
6
Copyright © 1996 by ASME
the many unresolved problems with transaction processing in such a database environment [Ozsu91], only automated querying of the shared data is provided while leaving the data updates to individual designers using corresponding CAD tools. The meta-level DIS can suggest to these users to modify the corresponding application models using E-mail or other similar messages and thus provide only an indirect transaction processing. It was further decided to use an object-oriented data model as the most appropriate to represent the complex relationships typical for engineering design data. The following major entity classes for an integrated DIS database were identified: • Product Data - design parameters (variables), product components and functional units, and design constraints (relationships between other product data entities which can be interpreted and evaluated by the DIS or its user) • Design Processes - primitive design activities (operations), design tasks (the smallest design procedures significant from design process management point of view which bear the temporal information), design sub-projects and projects (semantically important composite design processes comprised of one or more tasks). • Organizational Units - person, design group (a group of persons working on common design tasks), department, company, etc. • Sources of Information - computer network-based resources (e.g., the electronic edition of the Thomas register), paper documents (e.g., books, journal articles, catalogs), and consultations with fellow designers. The process and rationale for the selection of these major classes as well as some class-specific attributes are available in [Bliznakov95b]. Only the common characteristics of all the classes are detailed in this work. One of the common characteristics of most of the major classes ( except for the last one) is that they can be subdivided into a primitive and one or more composite entity classes. Composite class instances can reference corresponding primitive class instances either as attributes or components. They can also have specific application model files (BLOBs) associated with them (e.g., a geometric model associated with a product part entity). These files are intended for access through CAD and other software tools interacting directly with the end user. As the design process is a decision making process, each of the entities could be not only a specific instance, but also a selection of one instance from a list of several alternatives. This is most obvious in the case of product data. For example, one design parameter value could be chosen from several possible alternatives, one design constraint (e.g., an equation to determine a value for a design parameter) can be selected from a list of alternative empirical methods. The same, however, holds for the entities of all other major classes. For example, a designer to perform a given task can be chosen from a list of possible
candidates, or one design task can be preferred over another based on test results. To record the decision making process, pros and cons for each alternative and the rationale for the selection made are added. Another characteristic common to the product data and (to some degree) design processes, organizational units, and sources of information classes, is that the data evolves throughout the engineering design process. To allow for a better coordination of designers’ work in a concurrent and cooperative environment, a value indicating the confidence level of the data owner (i.e., the "stiffness" vs. "flexibility" of the specific instance values) at any given point of time hints to other participants in the design process of possible changes. This measure of confidence is also influenced by the method used to determine the data value(s). For example, a design parameter can be assumed (something which provides more flexibility to change it further in the design process), determined (using some design constraint), obtained from an information source (book, catalog, standard specs, consultation), etc. As another example, physical laws are completely rigid. Constraints deduced from them cannot be released or circumvented. While technically it is possible to compare values of the confidence levels / stiffnesses for different data entities, this attribute at the current point is meant to have a more qualitative character. In the future, it might be used for automated probabilistic analysis. Entities from most of the major classes are related to each other. A common relationship throughout all data classes is a link to only one person - "owner" at any given time. The "ownership" can be passed as the design progresses through the development cycle. In addition, participants in the design process can indicate their interest in a specific piece of data. This information allows automatic notification of concerned parties about modifications. 7. FUNCTIONAL ARCHITECTURE OF THE INTEGRATION INFRASTRUCTURE An infrastructure to support concurrent engineering and cooperative design on the Internet was devised through this research. The proposed meta-level DIS, as any information system in general, can be subdivided into user interface manager, database, and DIS application modules operating on the data from this database. In addition, due to the specifics of the integration infrastructure, two more major components can be identified: CAD and other application software systems which need to be "glued together" by the meta-level DIS and their application data models. The user interface management system is responsible for the management of the dialog with the user. A typical user interface manager itself has three major modules [Bliznakov95c]: presentation module, dialog manager, and application interface. The first one - the presentation module - is responsible for the direct interactions with the user: character and/or graphics display, text and/or graphic input, etc. The function of a second module - the dialog manager - is to decide upon the subsequent status of the
7
Copyright © 1996 by ASME
dialog based on user’s actions. For example, it is responsible for deciding which menu or input form needs to be displayed next based on a previous user input. The application interface is responsible for invoking appropriate functions (e.g., database access functions) and passing them the user input when the dialog manager determines that this was requested by the previous user action. The shared database maintaining the global conceptual view of the data and knowledge stores the meta-schema information for the integrated model as described in section 6. Since in a CAD environment the meta-schema evolves, a meta-schema evolution component is included. In addition, the database might store the static data checked for some reason into the database (e.g., to store several versions of "snapshots" of the design before the models are modified through the application programs). It also includes pointers to dynamic data sources (e.g., exported parts of the individual application data models) and a communication component to access them. The DIS application modules operating on the global conceptual view data perform such functions as query reports based on the integrated data and design constraint maintenance across different CAD systems (e.g., to verify that the value of the same physical parameter in two different application models is the same). The application CAD software provides methods to manipulate its local data. For example, a spreadsheet program allows to set up values for different variables as constants or expressions involving other variables. It updates automatically
local data model with the integrated model. Some of these methods represent static neutral format file exchange, while others allow dynamic access to exported parts of application models. 8. IMPLEMENTATION ARCHITECTURE OF THE INTEGRATION INFRASTRUCTURE The architecture described in the previous section could be implemented in different ways. Some of the options are: using a client-server architecture database, using remote procedure calls, by exporting the X display of an X-Window based application program, etc. Building the DIS on top of the WWW was selected. The major advantages of this approach come from the fact that the Web became a focal point of massive efforts of many talented people: • Low-cost or even shareware basic (client and server) software is broadly available • The issue of data security is tackled at the basic software level • A lot of information which can be used in the design process (e.g., component catalogs, properties of materials, etc.) is already available on the WWW and the user can transparently access it and address it through the DIS • Scalability - the WWW is easily expandable • Global nature of the WWW • Wide range of hardware devices supported • Standardized interaction techniques, hence, easier user training and shorter development time • Possibility to reference multimedia records (text, graphics, video, and audio) Table 3. Possible mappings between the components of the functional architecture and the components of the implementation architecture. Implementation Informatio Informatio Informatio Functional n Client n Request n Server Broker UI Presentation + Module UI Dialog Manager (+) + UI Application (+) + Interface to DIS modules DIS Application (+) (+) + Modules DIS Global Data + View Application + programs (CAD systems and other applic. software) Application Data + There are few disadvantages of this approach too. The major ones stem from the fact that HTTP, the protocol used to exchange data on the WWW, is stateless at present. The servers do not maintain the status of each interactive
Information request broker Information servers
Internet
Information clients
User queries
Dynamic data retrieval
Application model file(s) and mobile application(s) retrieval, remote software access
Figure 3. Overall architecture of integrated infrastructure implementation. the values for dependent variables if the values for the independent variables are changed. Similarly, a geometric modeling program might allow the user to create models of solid objects by Boolean combinations between primitive volumes, modify them, calculate properties such as area, volume, coordinates of the center of gravity, moments of inertia, etc. As noted in section 4 (table 1), the application software can provide different ways of sharing parts of their
8
Copyright © 1996 by ASME
session; it is, in fact, limited within a pair of a request (from the client), and a reply (by the server). There might be cases, however, in which a more sophisticated exchange of data might be needed. For example, possibility for both the client and the server to initiate the dialog might be required. Alternatively, a reply to more than one client, not just the one which initiated the transaction might be needed, etc. Despite the few shortcomings, the advantages of the approach based on the WWW suggested pursuing it. A three-tier implementation architecture is proposed (figure 3). From a functional viewpoint there are three roles in this logical implementation architecture: information clients, information servers, and one or more information request broker(s). Physically, all three roles can be incorporated in the same computer connected to a network (e.g., Internet) by running both client and server software on it. Ultimately, combining a client and a server within each workstation transforms the client-server architecture into peer-to-peer architecture. Table 3 shows possible mappings between the components of the functional architecture (as described in section 7) and the components of the implementation architecture. The client’s role is to maintain the direct interaction with the user (figure 4). The presentation module of the user interface manager has to be incorporated in the client software. In addition, if the client is capable of maintaining a hierarchical dialog status locally the dialog manager module can also be built into the client software. For example, since recently (after the advent on a broad scale of the mobile computing paradigm and languages like Java ) the WWW clients can maintain the dialog status locally. As an alternative, the dialog manager can
in turn accesses the OODBI layer. The latter retrieves information from the database, which might include references to remotely stored information (stored as URLs). After receiving back the information from the OODBI, the communication layer attempts to resolve the external references to data and mobile programs by acting as a WWW proxi. It makes secondary HTTP requests and expects information back from information servers (figure 6). The latter process the requests from the broker using SNAs - small programs which provide dynamic access to the exported part of a specific CAD tool application model. Currently, such SNAs can be written using the particular API calls to access the CAD tool database, or read in and filter static files in some standard format (e.g., IGES or STEP). With the development of standard SDAI interfaces by CAD tool vendors, they can be used to code single SNAs which can serve multiple CAD systems. Alternatively, with the appearance of CORBA-compliant software tools, gateways between WWW and CORBA can be used to access them using CORBA interfaces. SNAs return back to the information broker object class instances. The protocol, according to which this is done is described in [Bliznakov95a]. This protocol, called HEXAPro, was designed in such a way that the information can be processed by the broker or, alternatively, can be viewed directly by a WWW browser if the user makes a direct request for one reason or another. With the advent of the mobile computing paradigm, the information broker can provide distributed access not only to data but to software as well. For example, the software agent for a design constraint evaluation can be downloaded along with the values of participating design parameters to client’s software. Thus, the user can get locally quick response to "what if" type of queries, e.g., "Will the constraint be violated
Execution of remote applications
WWW server Internet
WWW browser Internet Local execution of applications
User UI layer
Communication layer
Figure 4. Client site architecture. be on the information broker site (which is the case in our implementation). In this case, the status of the dialog needs to be coordinated between the information client and the information request broker. A typical information request is made by the user employing a WWW client software. The request is processed by the UI layer at the information broker site (figure 5). UI layer replies itself in some cases (e.g., to offer a menu of choices or an input form back to the user). However, when information needs to be retrieved, the UI layer passes the request to the communication layer, which
WWW script (executable program)
Links to Information servers
OODB OODB interface
Figure 5. Information request broker site architecture.
9
Copyright © 1996 by ASME
• Sub-class - super-class • Class - attributes • Composite entities - primitive entities • Class - instance Both top-down and bottom-up approaches are made available to the user for additional convenience. For example, when a product component is being specified, the user can select its attributes from a list of currently defined design variables. If the one needed is not in the list at the moment, the user can select the new operation, define the design parameter, and then return to the component definition process (with the newly created design variable already available). Similarly, when the user wants to specify a search condition for an instance of the department_team class rather than selecting the name of a known team member from a list the user can opt for the identify operation and recursively search by specifying arbitrary search condition, this time for a person. In the engineering design domain the basic user interface functions mentioned above might be relatively complex. For example, the display function for a product component might require visualization of a 3-D geometric model or a scanned photograph of the part. Similarly, the edit function might require a more complex capabilities than simple modification of attribute values. For example, an equation interpreter software can be downloaded to allow the user instant feedback when s/he modifies the design constraint or any of the participating design variables ("what if" mode). The object-oriented paradigm allows convenient re-definition of the default basic user interface methods.
WWW server Internet
Static exchange file Application model file
(1) (2)
Software network adaptor(s) CAD or other application
WWW script (executable program)
Remote execution
(1) Upload of application model file(s) (2) Upload of mobile application software
Figure 6. Information server site architecture. if the value of the first parameter is changed that much ?". Once a satisfactory combination of parameters is achieved, they can be submitted for further processing (e.g., for updating the related models). In a more "traditional" CAD environment, the meta-level DIS can be used to start remotely application software, or download required application model files or neutral format files and pass them to locally run application software. Such functionality provides additional convenience to the user. The latter can be implemented by the mechanism of external viewers and various application/* MIME types. 9. USER INTERFACE OPERATIONS The interactive operations which are included in the DIS are common to database systems in general: record an instance (or define a new subclass), retrieve, modify, delete, as well as aggregate functions (find maximum / minimum / average / sum / count). These operations are further mapped onto the following user interface functions: search (by specifying a search condition and possibly further selecting from a list of matching instances), display instance or class information (including hyperlinks to related entities and classes), and edit (given the current state of an instance). For example, the delete function allows the user to specify a search condition by giving values of instance attributes, then to select instances from a list of matching ones, and lastly to see selected instances and confirm the operation. The modify function asks for a search condition, allows the user to select a matching instance for the operation, and then displays an input form with the current attribute values as defaults which can be edited. To allow more flexibility in specifying search conditions, the user interface allows to define an arbitrary combination of lower and/or upper limits and/or wild-card character strings to match attribute values. The display function makes use of buttons to allow browsing through object instances and classes along various relationship links. Therefore, retrieval by direct searches can be followed by browsing from one related object instance (or class definition) to another. The relationships pertaining to most of the classes which are represented as link buttons are:
10. DISCUSSION The problem solved by this work was dynamic integration of design product and process information in a distributed heterogeneous environment through a meta-level design information system. This work focused on routine cases of mechanical design (matching design and configuration synthesis), although the results are more or less applicable to various types of design and various stages of the design cycle. Taxonomies of CAD and other application programs with regards to their integration “friendliness" and possibilities for remote access by the end-user were developed. These taxonomies can be used by CAD vendors as a guidance for development of software which can be easier integrated in a higher-level DIS. They are also used to catalogue different applications and their data models in the DIS. An object-oriented data model for the DIS was developed. It includes all the major classes of entities in engineering design: product data, design process, participants in it, sources of information, etc. A methodological issue, which was resolved, is the identification of the shared parts of individual application data models which are to be exported to the global data view. It is suggested that these shared parts include (1) data needed to maintain inter-application relationships (e.g., constraints); (2) data needed to answer queries from
10
Copyright © 1996 by ASME
participants in the design process which are not addressed by individual application programs and (3) application data needed to support user queries in cases where the specific application programs cannot be or are not accessed directly by the users for one reason or another. The dynamic access and interoperability of CAD tools is provided by an information broker. It processes user queries and dynamically accesses the information from CAD tools (which act like objects on the WWW) if needed. The CAD tools interface is provided by software network adapters. They export parts of the local application models as needed. A protocol for information exchange between the information broker and the software adapters is developed. The proposed data model was used to record the information from a large multidisciplinary student design project at Arizona State University [Shah95]. Static hypertext files were used to prototype partially a dynamic interface (without allowing structured queries about specific class instances). The prototyped interface was used to gather some usage statistics about different data instances [Bliznakov95b]. Currently, a dynamic interface is under implementation. Once completed, it will be used to record data from a design project. The system will be verified by attempting to answer queries formulated by designers. The test queries are being collected through interviews with designers.
Computers in Engineering Conference and the Engineering Database Symposium, Boston, MA. CAM-I, October 1990, Application Interface Specification (AIS) 2.0, R-90-PM-03. CORBA, 1995, "Common Object Request Broker Architecture (CORBA) - Repository of Materials", 1995, http://www.acl.lanl.gov/sunrise/DistComp/Objects/corba.html Encarnacao, J., and Krause, F., 1992, (ed.), File Structures and Databases for CAD, North-Holland. Gosling, J., and McGilton, H., 1995, "The Java Language Environment: A White Paper", Sun, Microsystems, Inc., http://java.sun.com/whitePaper/javawhitepaper_1.html Granacki, J., Knapp, D., and Parker, A., 1985, “The ADAM Advanced Design Automation System: Overview, Planner, and Natural Language Interface,” Proceedings, 22nd Design Automation Conference, pp. 727-730. Harder, T., Meyer-Wegner, K., Mitschnag, B., and Sikeler, A., 1987, “PRIMA - A DBMS Prototype Supporting Engineering Applications,” Proceedings of the VLDB, Brighton, England, pp. 433-442. Hardwick, M., and Spooner, D., June 1989, “The ROSE Data Manager: Using Object Technology to Support Interactive Engineering Applications,” IEEE Transactions on Knowledge and Data Engineering, Vol. 1, No. 2, pp. 285-289. Hardwick, M., and Loffredo, D., September 1995, “Using EXPRESS to Implement Concurrent Engineering Databases,” ASME Computers in Engineering Conference and the Engineering Database Symposium, Boston, MA. Hubel, C., and Sutter, B., 1992, “Supporting Engineering Applications by New Database Processing Concepts - An Experience Report,” Engineering With Computers, Vol. 8, pp.31-49. Initial Graphics Exchange Specification (IGES), Version 4.0., June 1988, National Institute of Standards and Technology (NIST), Gaitherburg, MD. ISO 10303: Product Data Representation and Exchange: Part 22: Standard Data Access Interface, ISO TC184/SC4/WG7N302, May 1993. JavaScript Authoring Guide. Netscape Communications Corp., December 1995, http://home.netscape.com/comprod/ products/navigator/version_2.0/script/script_info/ Jeon, D., Urban, S., Shah, J., Liu, H., Bliznakov, P. and Rogers, M., , May 1995, “Metadata Extensions to an ObjectOriented Data Model for the Dynamic Capture of Engineering Design Histories,” IFIP Working Conference on Database Semantics, Stone Mountain, GA. Magleby, S.K. and Gunn, 1992, “Flexible Integration of CAD/CAM Modelers and Application Programs,” Technical Report, Brigham Young University. Ozsu, M.T., and Valduriez, P., 1991, Principles of Distributed Database Systems, Prentice Hall, Englewood Cliffs, New Jersey. Rangan, R., Fulton, R., 1992, “A Data Management Strategy to Control Design and Manufacturing Information,” Engineering with Computers, Springer-Verlag, New York pp. 63-78.
ACKNOWLEDGMENTS The work reported in this paper was in part supported under a project funded by the Scientific Databases Program, with additional funding from NSF Design Theory / Methodology Program (Grant no. IRI-9117143). REFERENCES ACIS Geometric Modeler, Application Guide. Version 1.7. Spatial Technology, Inc. Three-Space, Ltd. and Applied Geometry, Corp., July 1995 Afsarmanesh, H., D. McLeod, D. Knapp, and Parker, A., 1985, “An Extensible Object-Oriented Approach to Databases for VLSI/CAD,” Proceedings, Very Large Databases Conference, Stockholm, pp. 13-24. Batanov, D., Bliznakov, P., Bojkov, D., and Pavlov, G., May 1984, “A Comparative Survey of Mechanical Engineering CAD Systems,” Proceedings International Conference on State and Progress in FMS, Prague, Czech Republic, (in Russian). Bliznakov, P., October 1995, “An Object-oriented Approach to Design Process and Product Information Exchange on the WWW,” Position paper presented at Workshop 1: Objects, Scripts, and the Web. OOPSLA '95, Austin, TX. Bliznakov, P., Shah, J., Jeon, D., Urban, S., September 1995, “Design Information System Infrastructure to Support Collaborative Design in a Large Organization,” ASME Design Automation Conference, Boston, MA. Bliznakov, P., Rogers, M., Khan, N., Ali, A., Shirur, A., and Shah, J., September 1995, “User Interface Design for Feature Modelers and Feature Based Applications,” ASME
11
Copyright © 1996 by ASME
Shah, J., Bliznakov, P., and Urban, S., September 1993, “Development of Machine Understandable Language for Design Process Representation,” Proceedings of ASME Design Theory and Methodology Conference, Albuquerque, NM. Shah, J. et al., September 1995, “The Virtual Corporation - Simulating Collaborative Design in the Real World,” Proceedings, ASME Design Theory and Methodology Conference, Boston. Shah, J., Jeon, D., Urban, S., Bliznakov, P., and Rogers, M., “Database Infrastructure for Supporting Engineering Design Histories,” Accepted to the special issue of CAD Journal titled "Computer Aided Concurrent Design." Urban S., Shah, J., Rogers, M., Jeon, D., Ravi, P., and Bliznakov, P., 1994, “A Heterogeneous, Active Database Architecture for Engineering Data Management,” International Journal of Computer Integrated Manufacturing, Vol. 7, No. 5, pp. 276-293. Vossen, G., Bimmermann, R., and Buchholz, G., 1988, “Providing Database Management for the CAD Environment: The AREDAS Approach,” Engineering with Computers, Springer-Verlag, pp. 207-223. Wang, F.-C., Richards, B., and Wright, P.K., September 1995, “A Generic Framework for Integration of Mechanical and Electrical CAD Tools for Concurrent Design of Consumer Electronic Products. ASME Computers in Engineering Conference and the Engineering Database Symposium, Boston, MA.
12
Copyright © 1996 by ASME
