Position paper for the Open OODB Workshop at Texas Instrument Dallas, Texas March 13-15, 1991 Data Sharing Needs of Manufacturing and Engineering K. C. Morris kc@cme.nist.gov March 7, 1991 Factory Automation Systems Division National Institute of Standards and Technology Bldg. 220 / A127 Gaithersburg, MD 20899 This paper summarizes the needs for standardization with respect to data access and sharing in a manufacturing and engineering environment, the work that is currently being done in these directions within the STEP project (ISO/TC184/SC4), and the role of the National Institute of Standards and Technology (NIST) in this effort. The paper is intended to describe these topics as a basis for discussion at the DARPA-sponsored Open OODB Workshop on March 13-15, 1991 at Texas Instruments. 1 Introduction NIST is actively involved in the development of the International Standard for the Exchange of Product Model Data (STEP). STEP is a conceptual specification that forms a basis for communicating product information at all stages in a products life-cycle, covering all aspects of product description and manufacturing specifications. The fundamental components of the STEP are product information models, and standards for the means of exchanging information corresponding to such models. This development activity is supported by a consortia of industrial corporations (PDES, Inc.: PDES stands for Product Data Exchange using STEP) and a major activity of the Department of Defense's Computer-Aided Acquisition and Logistic Support Office (CALS) [Furlani90]. NIST is itself active in some areas of model development and in the development of the exchange mechanisms. In addition, NIST administers the National PDES Testbed [McLean90]. The Testbed is used in the validation of information models being proposed as part of the STEP [Mitch90], as a facility for conducting prototype implementations of systems using the STEP models and exchange mechanisms [Fowler90], and in the investigation of the suitability of new technologies to the application areas covered by STEP. Until recently the STEP community focused on the use of exchange files for communicating information about products; now there is an effort underway to define a mechanism for sharing such information more dynamically and at a finer level of granularity through the use of database management systems. Within the STEP community the different types of data sharing are referred to as levels of implementation. Level 1 refers to sharing by means of an exchange file; level 2 refers to data sharing using a standard in-memory data format; and level 3 refers to data sharing using a database management system as the means of data storage and access [Alte88c]. The underlying assumption when sharing data using STEP is that the data in question corresponds to an agreed upon integrated conceptual schema. While this is extremely useful for the exchange data in a neutral file format, sharing data directly through a database management system is much more complex. Among the things to be considered in such an environment are how to access the data, how to limit access to data in such a way that a foreign system would be able to access only those data which are desired and not other information in the system, how to locate data in a shared and distributed system, and how to integrate the STEP models for data into an enterprise's global data system. These are considerations which have begun to be addressed by the STEP development community. The initial thrust of the STEP development effort, to build information models to represent structure and semantics to be associated with shared data, was a difficult task. It required agreement on standard product information models, a language for representing these models, and the specification of an exchange format. The requirement to support the models of existing CAD and CAM systems has made achieving consensus on the content of the standard product information difficult because the models often overlap and conflict. For example, a curve through space can be represented as a b-spline, as a list of curve segments, or as a non-uniform-rational b-spline (NURB). The STEP modelers have undertaken the very difficult job of defining mappings between the different representations of the same information. The need for language capable of reflecting such rich semantics and data structures resulted in the specification of the language Express. Among other things this language provides for the representation of classes of data, in both hierarchies and networks simultaneously, and of constraints on the data. The format of the STEP exchange file mirrors the Express language. The STEP Data Access Specification (SDAIS) [ISO-N499], which currently under development, is based on the requirement for a means of dynamically accessing data defined using the Express language. It is likely that the exchange format which results from this work will resemble the STEP exchange file format. At the organizational level this format is needed for the exchange of objects across a "service backplane", such as is described in the TI-proposed architecture. Version 1 of STEP [ISOa] (targeted for release in July 1991 as a standard under ISO/TC184) will consist of a group of clearly and formally defined information models (covering applications areas of geometry, presentation, and draughting), a language for specifying those information models, Express [ISO-N5], and a protocol for representing exchange files based on these models [ISO21]. New work items are underway for specifying information models in other application areas and other methods of data sharing. The STEP Data Access Interface Specification [ISO-N499] is being developed for the next version of STEP; this standard will specify an application interface to STEP data. Other investigative work has begun to determine the feasibility of sharing data directly from database management systems and to determine where standardization would be suitable to enable data sharing in such an environment [PDES91]. NIST has an active interest in object-oriented information models, in the manipulation by application programs of information bases using such models (the Application Interface in the TI architecture model), and in mapping conceptual models and manipulations onto a common object-oriented "service backplane", such as that provided by the TI-proposed architecture. 2 Data Sharing Needs for Manufacturing and Engineering The following is a list of industry needs that have been identified which an open database environment should address (the text is adapted from [PDES91]): The product design industry needs major improvements in the efficiency, timeliness, and cost of doing business. It is widely acknowledged that achieving these improvements requires industry-wide standardization of the information used to design and build products, including information about how design data is stored and shared. The specific requirements for standardized data models and formats and standardized methods of manipulation and navigating through data storage facilities have already been addressed (or are being addressed) in PDES Levels 1 and 2. There are many additional and more complex requirements that can only be met in a shared data environment using database technology. There are three basic areas where data sharing using database technology is needed: o Within a work group of design engineers - a small group of highly specialized engineers who work together on specific areas of product design such as solids modeling, finite element analysis, or printed circuit board layout. o Across the full product life cycle, with an assumption that various releases of the product are needed during different stages of the development process. Typical process stages where data sharing is crucial are (1) moving from conceptual product design to detailed product design, (2) moving from design engineering to manufacturing engineering, and (3) moving from first prototype manufacturing to volume production. o Between enterprises in a vendor/supplier relationship, a contractor/sub-contractor relationship, or some other collaboration between different companies or divisions. 2.1 Data sharing needs of groups of design engineers Users of CAx applications need a design environment where data is stored and managed as a single "unit", accessible at any time by any application. This type of data sharing is different from the data exchange (file exchange) used in PDES levels 1 and 2. The single unit of data may be partitioned and physically distributed across several different systems. Design changes must be maintained centrally so that new versions of the design are easily and quickly available to all members of a design team. Members of design teams need to work independently without concern for whether others might be doing duplicate or conflicting work. Users need to manipulate and navigate through both entire designs and portions of designs. Today's DBMSs support these needs with their facilities for persistent data storage, partitioning design data, controlling user access to data, and managing multiple users. 2.2 Data sharing requirements across the product life cycle There are requirements for management of data security, application workflow, work planning, configuration and version control, product release, and other issues related to product development and life cycle, all within a multi-user, multi-tool environment. Today's DBMSs have limited facilities for managing these types of information, but they are being widely enhanced in these areas. 2.3 Data sharing requirements between enterprises Within enterprises there is a need to integrate data both vertically (up and down a single business organizational chain) and horizontally (between different organizations). DBMSs provide facilities for making this possible. 3 Software Technology Needs Software engineers who develop and maintain CAD applications and database systems need to make their systems easier to "mix and match", need to quickly evolve software as new software technologies or algorithms become available, and need to accomplish all this with high software quality and low development costs so they can maintain their competitive edge. Three groups can specificly benefit from the development of standards: o Data storage technology developers benefit from standard interfaces by allowing them to concentrate exclusively on database technologies to meet evolving user needs o CAD system providers and application developers benefit from standard interfaces by allowing them to concentrate on application-specific algorithms and simplify the addition and removal of tools from a system o System integrators benefit from standards for conceptual schemas, such as STEP, which allow them to focus on the problems of interfacing different physical representations of data including managing the distribution of data across multiple enterprises, between different hardware platforms, between different data storage paradigms and systems, and across a variety of network architectures. 3.1 Data Storage Technology Developers of data storage technologies need to provide facilities to handle heterogeneous, multi-technology environments, which exist today for product designers, and are expected to proliferate and become more complex in the future. Not only may related pieces of data be stored in separate databases, but they may be stored using different database technologies. Different types of product data may be best suited to different storage technologies, and the details of those technologies will change over time. Existing and future technologies include but are not limited to ASCII files, binary files, relational DBMSs, object-oriented DBMSs, and Knowledge-Based DBMSs. There is also a need to have data storage mechanisms be transportable across operating systems, which is addressed by standards such as POSIX. Existing DBMSs do not handle all these needs today, but the necessary enhancements are being actively developed. 3.2 Application Development Environment Developers of CAD applications need to quickly incorporate new algorithms and features in their software to meed evolving product designer needs, and need to make their applications easy to add and remove from installed systems, all with low cost and high quality. They need to do this without concerning themselves with the details of the underlying storage mechanisms. Data storage technology has become sufficiently complex that it is not cost-effective for application developers to also develop databases. To meet these requirements it is necessary to isolate applications from data storage facilities, so that application developers can concentrate on what they know best, and rely on database providers to do the same. When applications all use standard interfaces, system managers will be able to easily re-configure CAD systems, adding and deleting applications without extensive re-coding. Sharing the same data repository among applications will also eliminate the need for new translators (readers and writers) for each additional file format needed by a new application added to the system. 3.3 System Integration Technology Developers of tools for integrating computer systems first need to define conceptual mappings between the data of the various systems. After the data is conceptually mapped between systems, then the integrators can focus on the other problems mentioned above (the management of the distribution of data across multiple enterprises, between different hardware platforms, between different data storage paradigms and systems, and across a variety of network architectures.) Standards such as those for describing product model data (i.e. STEP) [ISO21, ISO-N499] will assist in the goal of system integration by providing a basis for mapping existing systems to standard conceptual schemas as defined in STEP. Using such a standard the task of mapping between various systems is reduced in complexity. Instead of defining a mapping between each system and every other system (which would be n**2 mappings where n is the number of systems involved), the integrator will only need to define the mapping between each system and the standard conceptual model (which is n mappings). The SDAIS, which is a set of standard procedure calls to be used in applications directly, is one example building block for providing a consistent interface to the systems through a standard conceptual schema. System integrators also need to manage all the software components of the integrated data system. Tools for managing conceptual schemas, data, and workflow, and tools for controlling versions and system access are needed. Many of these needs are being addressed by standards for Information Resource Dictionary Systems (IRDS) under ANSI and ISO. Schema management refers to the ability to trace the usage of components of the conceptual model through out the integrated data system. This allows the system integrator to track what program modules would be affect by changes to the standard schema; it also gives the integrator some indication of the interrelationships between the modules. There is also a need to make the standard conceptual model automatically accessible to the programs and systems which are going to make use of it. Version control refers to the management of changes to both individual software systems and versions of the conceptual schema; the updating of system components to newer versions must be facilitated. Workflow management governs among other things, which versions of software are compatible and in what order processes should be executed. Likewise, data management regulates what data is compatible with which programs and where the data is physically located. 4 Summary In summary, there are many areas where automation and interoperability of systems can greatly benefit the manufacturing and engineering industries as a whole. Tools to facilitate consistent access to data and otherwise manage the automated working environment are greatly needed. While many strides have been made in the area of automation, what has resulted is many islands of tools; now there is a greater need than every before to unify these tools into a cohesive environment. This problem is being approached by two angles. One approach is to provide a common basis for understanding of data used in the environment. This is being address by the STEP standard. The other angle, to provide tools to integrate the large amount of software components and data used in this environment, is being addressed in the IRDS efforts. While these approaches are not uncompatible, there is a need for an overall framework within which they both can inter-operate. The architecture proposed by TI should address this need. 5 References [Alte88c] Altemueller, J. PDES / STEP Implementation Levels, ISO TC184/SC4/WG1 Document N282, October 1988. [Fowler90] Fowler, James, STEP Production Cell, NISTIR 4421, National Institute of Standards and Technology, Gaithersburg, MD, September 1990. [Furlani90] Furlani, C. Status of PDES-Related Activities (Standards & Testing), NISTIR 4432, National Institute of Standards and Technology, Gaithersburg, MD, October 1990. [ISO21] Part 21 ISO TC184/SC4. Industrial Automation Systems -- Product Data Representation and Exchange -- Part 21: Clear text encoding of the Exchange Structure. [ISO-N499] STEP Data Access Interface Specification, working draft N499 ISO/TC184/SC4/WG7, Fowler, J., ed. [ISO-N5] Information Modeling Language Express: Language Reference Manual, working draft N5 ISO TC184/SC4/WG5, Spiby, P., ed., January 1991. [ISOa] ISO TC184/SC4, notes of the meeting of working groups in Eindhoven, The Netherlands, February 3-8, 1991. [Mitch90] Mitchell, Mary, Validation Testing Systems Plan, NISTIR 4417, National Institute of Standards and Technology, Gaithersburg, MD, October 1990. [McLean90] McLean, C.R., National PDES Testbed Strategic Plan 1990, NISTIR 4438, National Institute of Standards and Technology, Gaithersburg, MD, October 1990. [PDES91] PDES, Inc., Myles Barrett, George Coletta, Cliff Langenbach, Katherine C. Morris, Chris Mudgett, Augusto Nieva, A Strategy for Implementing a PDES/STEP Data Sharing Environment, working draft, January 1991. [Wilson90] Wilson, P., ed., Processing Tools for Express, working draft, October 1990. 6 Glossary STEP is a project of the International Organization for Standardization (ISO) Technical Committee on Industrial Automation Systems (TC 184) Subcommittee on Manufacturing Data and Languages (SC4). CAx is any Computer-Aided operations/processes, including MCAD (Mechanical Computer-Aided Design) e.g. drawing/drafting, ECAD(Electrical Computer-Aided Design), e.g. PCB layout, MCAE(Mechanical Computer-Aided Engineering), e.g. solids modeling, ECAE(Electrical Computer-Aided Engineering), e.g. logic design, CAM and CIM (Computer-Aided Manufacturing and Computer-Integrated Manufacturing), e.g. NC processing and photoplotting