A product information modeling framework for product lifecycle management

Abstract

The Product Lifecycle Management (PLM) concept holds the promise of seamlessly integrating all the information produced throughout all phases of a product's life cycle to everyone in an organization at every managerial and technical level, along with key suppliers and customers. PLM systems are tools that implement the PLM concept. As such, they need the capability to serve up the information referred to above, and they need to ensure the cohesion and traceability of product data.

We describe a product information-modeling framework that we believe can support the full range of PLM information needs. The framework is based on the NIST Core Product Model (CPM) and its extensions, the Open Assembly Model (OAM), the Design-Analysis Integration model (DAIM) and the Product Family Evolution Model (PFEM). These are abstract models with general semantics, with the specific semantics about a particular domain to be embedded within the usage of the models for that domain. CPM represents the product's function, form and behavior, its physical and functional decompositions, and the relationships among these concepts. An extension of CPM provides a way to associate design rationale with the product. OAM defines a system level conceptual model and the associated hierarchical assembly relationships. DAIM defines a Master Model of the product and a series of abstractions called Functional Models—one for each domain-specific aspect of the product—and two transformations, called idealization and mapping, between the master model and each functional model. PFEM extends the representation to families of products and their components; it also extends design rationale to the capture of the rationale for the evolution of the families.

The framework is intended to: (1) capture product, design rationale, assembly, and tolerance information from the earliest conceptual design stage—where designers deal with the function and performance of products—to the full lifecycle; (2) facilitate the semantic interoperability of next-generation CAD/CAE/CAM systems; and (3) capture the evolution of products and product families. The relevance of our framework to PLM systems is that any data component in the framework can be accessed directly by a PLM system, providing fine-grained access to the product's description and design rationale.

Introduction

PLM is generally defined as ‘a strategic business approach for the effective management and use of corporate intellectual capital’ [1]. PLM systems are gaining acceptance for managing all information about a corporation's products throughout the products’ full lifecycle. Global competition is one of the key drivers for many organizations to adopt the PLM concept and implement PLM systems. The PLM concept aims to streamline product development and boost innovation in manufacturing. Hence the PLM concept is a strategic business approach for the effective creation, management and use of corporate intellectual capital, from a product's initial conception to its retirement [1].

Even in the current (2003) economic downturn, many manufacturing companies are investing in PLM systems—to the tune of $2.3 billion this year [2]. We believe the reason why these companies are willing to take the risk is that these companies see PLM's potential to vastly improve their ability to innovate, get products to market faster, and reduce errors. According to industry analyst CIMdata, “For an enterprise to be successful in today's and tomorrow's global markets, PLM is not an option—it is a competitive necessity” [1].

A critical aspect of PLM systems is their product information modeling architecture. Here, the traditional hierarchical approach to building software tools presents a serious potential pitfall: if PLM systems continue to access product information via Product Data Management (PDM) systems which, in turn, obtain geometric descriptions from Computer-Aided Design (CAD) systems, the information that becomes available will only be that which is supported by these latter systems.

In this paper, a different approach to serving up information to PLM systems is proposed: a single PLM system support framework for product information that can access, store, serve, and reuse all the product information throughout the entire product lifecycle. This framework and its components are presented after a brief discussion of the PLM concept and of the major PLM system architecture and interoperability issues.

PLM holds the promise of seamlessly integrating and making available all of the information produced throughout all phases of a product's life cycle to everyone in an organization, along with key suppliers and customers. Manufacturers can shrink the time it takes to introduce new product models in a number of ways. Product engineers can dramatically shorten the cycle of implementing and approving engineering changes across an extended design chain. Purchasing agents can work more effectively with suppliers to reuse parts. Executives can take a high-level view of all important product information, from details of the manufacturing line to parts failure rates culled from warranty data and information collected in the field.

Because PLM systems grew out of product design software, company management tends to delegate the PLM concept to engineering executives, who traditionally have managed their own technology rollouts. While this hands-off approach works for choosing point solutions, such as CAD tools, it does not work well for a company-wide integrated platform. Different business functions generate and deal with product data in disparate ways. Manufacturing and engineering, for instance, work with a different version of a bill of materials—a listing of parts and subassemblies making up a product—than does purchasing, which also relies on approved vendor lists and catalogs.

For the PLM concept to be successful, issues such as establishing data standards and designing corporation-wide integration architectures need to be addressed so that formerly fragmented information can be served up to individuals in a format they can use. That way, people in various divisions are equipped to make key decisions—such as what products to introduce or what features to include in a product's design phase—when they are most cost-effective, rather than midstream in the parts procurement stage or even during manufacturing.

PLM systems are tools that assist a corporation in the implementation of PLM concepts. One of the main questions regarding PLM systems is: “What constitutes the PLM systems’ functionality?” The full PLM system functionality can be achieved by the specific components illustrated in Fig. 1. These are: (1) an Information Technology (IT) Infrastructure; (2) a Product Information Modeling Architecture; (3) a Development Toolkit and Environment; and (4) a set of Business Applications. The IT infrastructure is the foundation that includes hardware, software, and Internet technologies, underlying representation and computing languages, and distributed objects and components.

The product information modeling architecture includes product ontology and interoperability standards. The development toolkit and environment provide the means for building Business Applications that provide the initial functionality and enhance and extend the functionality of the PLM concept and could include kernels (e.g. geometry, math), visualization tools, data exchange standards and mechanisms, and databases. The business applications provide the PLM functionality that processes the corporate intellectual capital.

In two recent NIST workshops held in 2003, attempts were made to describe an architecture for the lifecycle-wide management and integration of product data [4], [5]. The architecture, as described in the working draft of the workshops’ summary report, is intended to provide a roadmap for the application of the diverse information technologies and computer science concepts that may be used to build and operate PLM systems supporting the full product lifecycle [6].

The domain of application for the resulting PLM system considered in the workshops deals with complex engineered-to-order systems, such as found in the aerospace and defense industries. The architecture defines two classes of views of product data: semantic views define constraints on the interpretation and usage of the information; while infrastructural views relate to the encoding and composition of data in the processes and tools in which it is used. Potentially applicable technologies are discussed in the working draft with respect to these two classes of views.

Some of the principal concerns expressed in the NIST planning meetings were the cohesion and traceability of product data. The conclusion was that current data management practices do not provide sufficient support of data cohesion and traceability. Cohesion and traceability, however, are complex and abstract goals when viewed as attributes of an information system. Information technology does not address these goals directly; rather, certain other qualities help to support these goals. Among the major constituent properties of cohesion and traceability identified were associativity across viewpoints and logical consistency [6].

PLM systems form the apex of the corporate software hierarchy and frequently implemented so that they depend on subsidiary systems for detailed information capture and dissemination. PLM systems therefore tend to delegate the task of managing the information describing the product itself to Product Data Management (PDM) systems. Furthermore, in many organizations, only the geometric description of products generated by Computer-Aided Design (CAD) systems is managed directly; in these organizations PDM systems rely on the CAD systems for managing product descriptions.

The above segmentation of PLM and subsidiary software systems results in three shortcomings. First, while PLM systems can track changes through the products’ lifecycle from conception to disposal, the information that describes the actual changes can be found only through the subsidiary PDM systems, and the reason for the changes may not be recorded in computer-processable form anywhere. Thus, there is a need to make product descriptions and their design rationale directly accessible from PLM systems, with no intermediary layers of software. Second, CAD representations of form (geometry) arise only at later stages of design, after a geometry has been assigned to the product concept; therefore, PLM systems tied only to CAD representations of products cannot be useful before the form is assigned. In order to realize the PLM concept's full potential, PLM systems need to interact with product information used in the early stages of conception and ideation, where designers and planners deal with the function and performance of products, and not yet with their form. Third, at the opposite end of the product's lifecycle, during manufacturing, installation, operation, maintenance and, eventually, disposal, the form of the product changes little, while much information is gathered about the product's behavior in these lifecycle stages. Here again, PLM systems tied only to CAD representations of products cannot be useful; PLM systems need to interact with product behavior information in the late stages of the lifecycle.

PLM systems are still in the very early stages and are in a flux. This may lead to the development of many proprietary systems and interfaces, which would result in additional interoperability problems. Hence we need national and international efforts to develop standards to alleviate future interoperability problems for PLM systems. We have made it our goal in the Product Engineering Program at the National Institute of Standards and Technology in the US to establish a semantically based, validated product representation scheme as a standard that supports the seamless interoperability among current and next generation computer-aided design (CAD) systems and between CAD systems and other systems that generate and use product. As part of this effort, we are developing a framework and a representation scheme that will address some of the above-mentioned issues.

The focus of this paper is the second component of the PLM system architecture presented in Fig. 1, namely, the product information modeling architecture. The aim of the paper is to argue that the Product Engineering Program's approach can: (1) support the full range of PLM information needs; and (2) overcome the three shortcomings of the PLM software segmentation discussed above. The paper is organized as follows. In Section 2 we introduce the NIST information-modeling framework. In Section 3, we describe the four components of the NIST information modeling framework. Further research issues to be addressed are discussed in Section 4. Finally the conclusions are given in Section 5.