Hannu Peltonen

Modelling generic product structures in STEP

Industrial companies need powerful data modelling mechanisms, e.g. classification, for the description of their products. The companies that adapt their products to the needs of individual customers in a routine manner have perhaps the most urgent needs. They must efficiently describe large numbers of product variants. STEP Application Protocol 214 (AP 214) for the automotive industry also addresses the modelling of product variants, i.e. generic product structure modelling. In addition to AP 214, the same mechanisms are needed in other standardization efforts as well, e.g. STEPlib of AP 221 and PLIB. STEP, however, does not include a mechanism for using classification and inheritance for modelling products of an individual company. These facilities are included in EXPRESS, but EXPRESS can only be used for describing the data schema to be standardized. The fundamental structure of STEP, therefore, prohibits a company from modelling its products in an object-oriented manner. This is an issue that may seriously affect the future of STEP as a general product-modelling methodology. The problems and possibilities of extending STEP in this direction within its current structure are discussed and a new mechanism is outlined as an alternative solution.

Multiple abstraction levels in modelling product structures

Abstract The need for product customisation is driving industrial companies towards a very large product variety, which affects many functions of a company, including the after-sales. Systematic maintenance records of very different product individuals cannot be kept without an abstract view to the population of delivered products. However, the older the product individual, the less systematically recorded information there usually is about it. We defined a novel mechanism based on generic models of product individuals organised into a specialisation hierarchy to support multiple abstraction levels. For creating such hierarchies, we defined a set of transformation operations on models.

Process-based view of product data management

Abstract Many companies consider acquiring a product data management system (PDMS) to reduce the delays and costs caused by inefficient product data management. There are, however, considerable differences between the various commercially available PDMSs, starting from the different meanings of basic concepts, such as document or document version. Before evaluating various PDMSs and their features, a company should analyze the processes in which the PDMS is going to be used. This paper describes two common processes: the development and delivery processes of configurable products. To a large extent product data is expressed as documents, and consequently engineering document management is one of the main functions of a PDMS. The rest of the paper discusses general requirements for document management within a PDMS and the particular requirements implied by the two process types.

Product Configurations - An Application for Prototype Object Approach

Product configuration management is presented as a practical application for a prototype-based object model. Data model requirements for a configuration system are first introduced using a realistic example from industry. Problems with the traditional type-instance model in this application domain are then identified and given as motivation for the prototype approach. A prototype-based object model with inheritance tree transformations, constraints and component relationships is presented as a tool for expressing dynamic configuration data. Finally, a sample configuration process is described using the prototype object model.

A design data manager

HutBase is a visual design data manager that can be used to store and manipulate data objects created and processed by a variety of design applications. In particular, HutBase allows the user to manipulate the data and start applications, and provides a access mechanism for the applications. HutBase consists of three software layers. The lowest layer, the Object Management System (OMS), is based on the Entity-Relationship model and includes those basic operations related to the storage and access of design data objects that are common to all applications. The database is divided into workspaces, which are collections of OMS objects and relationships organized according to an application-dependent schema and forming a significant whole (e.g., a design project) from the users point of view Workspace is also the unit for locking and access control. An object is a collection of attributes. Each attribute has a name and value. The name is a string and the value is an arbitrary sequence of bytes. The value of an attribute can be of any length, from a single integer to an external representation of a complicated geometric model. A relationship is a named directed connection between two objects. Relationships have attributes like objects. The OMS library contains functions for creating, opening and removing workspaces, objects, relationships and attributes. All operations are carried out within transactions. The functions do not change the permanent data on the disk until the user calls the save_changes function, which saves the current state of all workspaces opened in a given transaction. The next layer is a prototype data model built on top of OMS, which stores the objects in each workspace as a hierarchical tree by means of relationships. The leaves of the hierarchy are called representations and contain the actual data manipulated by the applications. Each representation is associated with a representation type, which in turn are linked to the application programs, or tools. The representation types and tools are stored as objects in a separate workspace. The top level contains a user interface and a procedural application interface. The user interface shows the available representation types, tools, and contents of one or more workspaces in iconic form. A representation can be opened by selecting its icon on the screen. The tool corresponding to the type of the representation is then started with a handle to the representation as argument. The interface also allows the user to create, remove and copy objects. The tool programs run as subprocesses of the HutBase process. Tools access the data base by remote procedure calls that send data base requests from the tool process to the HutBase process. The tools can also create relationships between representations and navigate in the workspace by following the relationship links. We are currently working on a interpreted definition language that can be used to describe the structure of a workspace. The definition language will be based on an object-oriented notation, where object and relation types form a class hierarchy. Class descriptions include (possibly inherited) methods for dealing with the various HutBase operations. With the contemplated description facility, new object and relationship types can be defined by declaring new subclasses of the existing ones.

An approach for supporting inter-application consistency

In a cooperative design environment many users need to be aware of modifications made to shared data. Traditional concurrency control mechanisms may cause data to be locked for long periods of time. A mechanism, which helps client programs to keep shared data up-to-date is presented. The mechanism is based on asynchronous notifications. In addition to ensuring consistency between different clients, the same model can be used to retain many consistent views (windows) to data cached on the client. The mechanism can be extended to support more complicated groupwork protocols.<<ETX>>