PDM Systems - Aalto University

Helsinki University of Technology PDM Systems TAI Research Centre Proposal 1.0 Arno Karatmaa 13.11.1998 1(39)

D:\data\GecosLocal\pdmupdated.doc

PDM Systems

ABSTRACT:

This paper provides information related to PDM systems. As goal there is to provideinformation which could be useful from point of view of distributed product develop-ment. There is information about how to choose PDM software, information aboutavailable products and some discussion about distribution and trends in PDM. There isalso presented concepts of PDM system.

DOCUMENT INFORMATION:

Project: GECOSDocument: PDM SystemsFile: D:\data\GecosLocal\pdm.docDeliverable:Publicity: GECOSVersion: 1.0Status: ProposalDate: 12.11.1998Author(s): Arno KaratmaaReviewed by, date:Checked by, date:Approved by, date:



TABLE OF CONTENTS

1. DEFINING PDM..........................................................................................................................................3

2. PDM SYSTEM.............................................................................................................................................4

3. PURCHASING PDM SOFTWARE.............................................................................................................43.1 Introduction.......................................................................................................................43.2 Understanding needs and dynamics of change..................................................................53.3 Getting overview of available software ............................................................................53.4 Functionalities...................................................................................................................53.5 Architecture ......................................................................................................................63.6 User interface....................................................................................................................73.7 Standards ..........................................................................................................................73.8 Miscellaneous issues.........................................................................................................73.9 Making list of requirements for the vendor.......................................................................83.10 Selecting software for closer review.................................................................................83.11 Testing selected software..................................................................................................83.12 Decision of purchasing .....................................................................................................83.13 Starting up new system .....................................................................................................83.14 Estimating results..............................................................................................................93.15 Evaluation of PDM software ............................................................................................9

4. PDM SOFTWARE .....................................................................................................................................104.1 MST 9000 .......................................................................................................................104.2 EnovianPM .....................................................................................................................124.3 Agile PDM......................................................................................................................134.4 Optegra ...........................................................................................................................154.5 Matrix .............................................................................................................................174.6 Metaphase.......................................................................................................................184.7 D-Iman............................................................................................................................194.8 Summary table of PDM products....................................................................................214.9 Guidelines for interpreting summary table......................................................................234.10 Summary of PDM products ............................................................................................25

5. LIST OF FEATURES IN IDEAL DISTRIBUTED PDM PRODUCT.......................................................26

6. DISTRIBUTION ARCHITECTURES .......................................................................................................28

7. CONCEPTS FOR DISTRIBUTED PDM...................................................................................................307.1 Introduction.....................................................................................................................307.2 Data.................................................................................................................................307.3 Metadata .........................................................................................................................317.4 System data.....................................................................................................................327.5 Observations ...................................................................................................................34

8. TRENDS IN PDM......................................................................................................................................35

9. SHIFT FROM LOCAL TO GLOBAL PDM..............................................................................................36

10. PDM MATERIAL IN INTERNET ............................................................................................................3710.1 Information sites .............................................................................................................3710.2 Linklists ..........................................................................................................................3710.3 Articles ...........................................................................................................................3810.4 PDM sellers in Finland ...................................................................................................39



1. DEFINING PDM

PDM stands for Product Data Management and is also know through othernames as terminology hasn’t settled down. It can be also referred as EDM (Engi-neering Data Management), PIM (Product Information Management) and inother ways, but essentially the issue is same. In this paper the term PDM is used,following the example in discussion forums of Internet and many magazines.

PDM is defined here in intuitive and practical way. PDM means managing in-formation of product and there are several simultaneous point of views.

PDM includes text documents, CAD files and other data objects like descrip-tions of files, which all contain information related to the product. PDM includesalso relations of these data objects with each others, which often forms a tree likeproduct structure, where product is divided into modules, and each of thesemodules are in turn divided into sub modules etc., until the preferred accuracy isachieved. On top of this there can be rules of allowed variations of basic modelof a product, which are called configurations of a product. These have been ex-amples of descriptive information about the product. However, configurationmanagement is a complex issue, and it may be handled separately of PDM.

In an organisation, there is also information about how existing data objects canbe used throughout the product development process. Access rules reflect com-pany policy and tell who has a right to read or change data and what is the scopeof these rights. There can be workflow to tell what should be the steps taken insome defined processes. State information might tell, that certain module is forexample accepted for production without further changes. There is also a needfor consistency rules to allow only one person to change the content of a par-ticular document simultaneously. These are examples of managing changes ofproduct information through various types of rules having state information ofproduct as help.

Through flowing of time and the dynamical nature of product as a real life ob-ject, there are changes in product information. This invites issues of life timemanagement of product information, which covers phases from manufacturingof individual product to end of its use. For example maintainance information ispart of life time management. Life cycle management of product informationconsists of phases from idea to design and production, until last product of thattype comes out of the product line. Especially interesting is the design process,which results many versions of the same product.

Naturally, product information should also be available in many different viewsto show in report only the needed part of product information. One view of aproduct could, for example, list its components together with prices. Searchingof certain information is related to views. Searching is on higher level; it picksdata objects based on rules; viewing shows a subset of information an objectcontains.



The above issues are fundamental for PDM. In PDM software products may alsocontain other useful features, e.g., project management, messaging systems tosupport workflow, and integration with other programs.

2. PDM SYSTEM

In this paper PDM system is seen as combination of people, work processes andtechnology in area of PDM. Technology has role between people and work proc-esses as provider of tools.

Software part of technology isn’t only about PDM specific software, but it in-cludes other programs which handle product data. There is links between pro-grams to transfer and convert information. Links can be anything between manu-ally typing information from one system to another to fully automatic links,where programs are integrated and act like there would be only one programwith common data vault and various interfaces to it.

Communication infrastructure of modern world has given new opportunities toPDM. It allows big distributed systems and question is, who can take advantageof possibilities and what is the right way to do it. What are the steps to updateexisting PDM systems and what are the boundaries of how far it is reasonable togo on a way into distribution.

As an invented example of PDM system there can be company which manufac-tures forest machinery. There is process which consists ideas, design, manufac-turing, selling and after sales. Every part of process handles product data and inwell implemented environment there are flexible links between task specificsoftware. Even if company processes would be local, clients might be global.Having distribution aspect in mind, there could be web browser interface for cli-ents for viewing different configurations of equipment and system for orderingspare parts as part of after sales.

3. PURCHASING PDM SOFTWARE

3.1 Introduction

Below is presented suggestion of process for buying PDM software. It is in aform of checklist, where points are expressed in chronological order of phases ofpurchasing. List is based on ideas in CIMdata’s Buyer’s Guide from year 1997.

Although there are many approaches for collecting information and base deci-sions on, it is good to point out, that purchasing PDM product is a very complexand difficult process. There are so many different point of views to consider andcompare with each others, trying to find optimal compromise not only for cur-rent situation, but also for the needs of the future. Even if there would be plentyof accurate information available this would be difficult, but especially difficultthis is, when amount of available information is limited and there are difficultiesto interpret and understand it.



As one example of difficulties to estimate information, is simple sounding ques-tion, weather considered PDM product supports distribution or not. Answer ’Yes’can be expected to be a guaranteed answer of PDM vendor. Problem is, that an-swer has so many dimensions, that it is difficult to understand what does it meanin practice, and is the type of distribution vendor is providing satisfactory fromthe perspective of actual needs. There can be big gap between offered type ofdistribution and needs. Question of distribution is introduced in the section ’Dis-tribution architectures’ later in this paper. Getting as accurate information as pos-sible is essential for reaching the expected outcome and making the right choice.

3.2 Understanding needs and dynamics of change

• What is the functionality software should provide?

• What are requirements for functionalities, for example minimum require-ments?

• How software would be used?

• What changes in everyday processes are tried to achieve or avoid?

• What changes in everyday processes would occur?

• Is there conflicting goals? What those are? What is priority of goals? What isvariation of goals among different users?

3.3 Getting overview of available software

• What is price range?

• What features are available in average software?

• What features are exceptional?

• What is variation in performance with selected features?

3.4 Functionalities

• How secure should software be? Is crypting needed? Is strong cryptingneeded?

• How detailed access configuration should be with viewing and modification?

• What links should be available between various objects? How paper docu-ments or other external data and links should be handled?

• How should be checking in and out arranged? How flexible should lockingbe?



• What kind of dataobjects should be available? How configurable thoseshould be? What type of metadata is needed? How flexible is adding newmetadata to objects? What kind of comments and markups are needed?

• What kind of version control is needed? Should there be approval function-ality or more extensive modeling and control of processes?

• What kind of structures are needed? Can various combinations of versions,conditions, options and substitutions be defined? What objects can be associ-ated to structures?

• What kind of views are available to structures and data objects? What kind ofreports about structures and parts are available?

• In what ways should structures be navigable?

• How well and easily can data be searched? What is the expression power ofquery mechanism? Can queries be recorded for future use?

• Are project management features needed like task lists and work breakdownstructures?

• What should be internal communication and notification mechanism like? Isemail integrated into software?

• Are data transfer features needed? Is there need for aliases and transferscheduling?

• Which data converters are needed? How automatic conversion should be?

• What kind of image viewing requirements there is? Can viewing modules beused independently of PDM program? Is there support for marking andcommenting images?

• How well administration features support user management, archiving andbackups, metadata definitions, data importing and exporting from other soft-ware?

• How good logging of events is needed?

3.5 Architecture

• On which operating system(s) should PDM software run? Is there support forheterogeneous environment? Is there clients for Windows, Mac or Javabrowser clients?

• On which hardware should software run?

• Is there web support? What kind of operations should be accessible throughbrowser?



• What databases are supported? Is there support for relational or object data-base?

• How open is architecture? Is there support for multiple CAD/CAM pro-grams?

• How secure should data storage system be? What support there is for this?

• What should be level of data distribution? Should software support multipledatabases and file servers? Can documents be saved to database?

• With what tools and programming languages is software made? How goodAPI support there should be for customizing and integration with other pro-grams?

• What kind of scripting and configuration possibilities should be available?

• Is there successful examples of integration with other programs? Is there im-plemented highly customized systems?

3.6 User interface

• How easy should user interface be? Can it be customized for different users?

• If there is many different interfaces available, are those consistent?

• How wide selection of interfaces there should be? Is there requirements forUNIX, Mac, Windows ,VT-terminal and browser interfaces?

3.7 Standards

• What data format standards are important? Is support needed for IGES,STEP, SGML or CGM? Is there need for ISO 9000 support?

• What communication protocols are needed? Is there support for TCP/IP,FTP, SMTP or ANSI X.400?

3.8 Miscellaneous issues

• Is there 3rd party applications available for the system?

• How wide is the user base of software? Is there user community with productsupport information in net in a form of web sites, newsgroups or mailinglists?

• How easy is software to install and administrate?

• How old is software? Where it is in use?



• What should be price? How much money is needed for software and hard-ware purchasing, implementation, installation, administration and consultingservices?

• What kind of changes in current operating environment are acceptable?

3.9 Making list of requirements for the vendor

• How strong vendor is? Is there future and development for the software?

• What is focus of the vendor? What kind of know-how there is?

• How good user support and training is available? Is vendor committed longtime partner? Can vendor provide tailoring?

• Note: Importance of vendor analysis might be easily over estimated. If theproduct is good, there is good potential also for the company behind theproduct. Even if vendor would get into trouble, there is high probability thatgood product continues its life under wings of another company.

3.10 Selecting software for closer review

• If possible, getting information about user experiences.

• Discussions with end users

• Selection is based on collected information and communication with vendor

3.11 Testing selected software

• Prototyping software

• Measuring performance data

• Comparing software with requirements and with each others

3.12 Decision of purchasing

• Discussions with involved parties

• Making synthesis of available information

• Making deal with vendor

3.13 Starting up new system

• Making plan for installation

• Making plans for collecting data of new system and new work processes

• Deciding metrics for quality, quantity, time and money measuring



• If possible, measuring should affect positively work processes

3.14 Estimating results

• Using software and collecting information

• Comparing results with goals

3.15 Evaluation of PDM software

In testing phase there can be used systematic methods. One readily available toolis Product Data Management System Evaluation Toolkit by Life Cycle SolutionsInc.

Key idea is to make various tests for PDM system and give points based on per-formance. Sum of points is calculated in a way, that for every step of each testthere is freely chosen weighting factor. To make calculation easier, there is pro-vided pre-filled Excel sheet with test steps and sum formulas in appropriate cells.

Written material is in two parts. In first part there is presented list of featureswith short explanations. For each feature there is also guideline of how to evalu-ate and give points for it. In second part of written material there is presentedeight tests which are divided into steps. From each step there is a reference tofirst part of material which gave the explanation and scoring hints. Material isfrom year 1995. In first part there is 63 pages and in second part 46 pages.

If every test and each step is taken to get results, it requires giving 296 pointsand related weighting factors. Number of related weighting factors is somewhatless than 296, since some points are grouped under same weighting factor.

It can be asked, if this kind of scoring is worth effort. Is giving points andweighting factors enough accurate method to give overall value of the system? Ifscore of another product is 320 and score of another 280, what is the meaning ofdifference? I would tend to think, that value of this material is based on given listof features, which can be used as help in process of making customized checklistof features. In similar manner proposed tests can be useful.

Although this kind of weighted features evaluations can be used, and there arehundreds of features to look for, there are still gaps between separate questions.Manuals of PDM products are best printed information there is available, andmanuals are still inaccurate and containing some outdated information. But if weare taking manuals as a reference point, it would take maybe 10 000 questions toaccurately picture whole PDM product, by giving 10 questions for each page outof one thousand.



Also, answers are often more complex than just a mark in a checkbox or ratingexpressed by single number. Questions are dealing with details, and may notcapture the performance of the system as a whole. Totally different approach,and probably more fruitful, could be to collect references in the same industryand get information from these sources. Even better it would be, if in the discus-sions there wouldn’t be present representative of the vendor, to get as good pic-ture as possible about the suitability of PDM product for the planned task. Thereis individual characteristic in every PDM product, which can’t be thoroughly un-derstood or noticed without longer period of usage in real life environment.

4. PDM SOFTWARE

This section shows light to what software there is available on field of PDM andwhat features are offered. In the world market there is tens of software packagesavailable. CIMdata’s buyer’s guide from year 1997 lists about 50 alternatives.Since this is too wide scope, software has been selected based on practical crite-ria. Most important criteria based on needs of companies is local vendor, sincePDM projects have potential to be long, complex and require tailoring and on-going communication with vendor. Another criteria for software are featureswhich support distributed environments, which can mean for example browserclient written in Java or distributed database with replication mechanism.

Source of information has been commercial material by vendors, to some ex-tent information through PDM demos and discussions. At few parts there is in-formation borrowed from CIMdata’s Buyers Guide.

4.1 MST 9000

4.1.1 Background

MST 9000 is made in Finland by Modultek. Modultek was established 1989 and1992 first version of MST 9000 was in the market. Since 1995 Modultek hasmaintained triple-A financial rating from Dun & Bradstreet. Modultek is origi-nated in Pori, and there is sales office in Helsinki and also joint venture office inJapan.

MST 9000 is used by Ponsse, company which manufactures forest machinery. Itis in use also in Hackman Metos, company which manufactures catering equip-ment and customised institutional kitchens. Metsä-Serla uses MST 9000 in itsKirkniemi paper mill. There are other installations as well in fields of discretemanufacturing, build-to-order and process industry. Current version of MST9000 is 5.0.



4.1.2 Features

• Support for workflow

• Product specific own mail system, which provides information weather thereceiver has his mail. Sending documents is implemented through sendingthose as references.

• Automatic notifications about changes in documents

• Whole document history available

• Configuration management

• Different views to data

• Project management, which allows splitting project into subprojects.

• Structure of database is at least partly parameterised, so that individual at-tributes can be added without changing code.

• There is some modular characteristic in implementation, for example docu-ment management is one independent module

4.1.3 Features to support distribution

• Java client soon ready for market

• Use of SSL technique with clients to protect information

• Access control is through group and individual profiles

• API for integration with other systems, like with MRPs

• Metadata is on one server, but documents can be loaded from different fileservers. Loading changed documents to another server can be done whenneeded or on certain moment of time. It is also possible to send files in slices,so that transfer doesn’t fill whole bandwidth.

• Macro language is available, which can handle for example DDE calls.

4.1.4 Environment requirements

• Server can be Windows NT or any UNIX, with minimum of 32 MB of RAM.

• Oracle database

• On a client side the minimum requirement is Intel 486 based PC.



4.1.5 Summary

To summarise MST 9000 from the point of view of distributed environment, itcan be said, there are many useful features which make distributed work possi-ble. There is possibility for more than one server for storing documents and thereare Java clients with encrypted connections. On top of this product can be cus-tomised through Macro language and parameters and there is API available forconnecting MST with other systems, which makes MST 9000 an open system,which is necessary in distributed environment. As one limitation it seems to be,that metadata is in one server and changing it isn’t allowed if network connectionis down.

4.2 EnovianPM

4.2.1 Background

EnovianPM is made by Enovia corporation, which was founded 1998 as awholly owned subsidiary of Dassault Systems. Dassault itself was founded 1981,and birth of Enovia corporation was to support alliance made with IBM, whichnow markets, distributes and supports Enovia products worldwide. Initial statesource code for EnoviaPM came from IBM, which owns 4.4 % of Dassault Sys-tems. As another productline Dassault has CATIA product family.

As examples of customers which are in a process of taking EnovianPM in useare Automotive system supplier Wilhelm Karman at five of its global plants withcontract of 900 seats. Alenia Aeronautica, munfacturer of military and civil air-crafts has signed contract of $4.5 million with Enovia corporation.

4.2.2 Features

• Out-of-the-box integration with following CAD systems: AutoCAD, CATIA,MicroCADAM, Pro/Engineer, Professional CADAM

• CATIA integeration allows automatic changes in product structures in Eno-viaPM based on changes in assemblies in CATIA.

• Out-of-the-box integration with following ERP systems: J.D.Edwards, Mar-cam and SAP (Baan integration coming)

• SAP integration is implemented to work in real-time and in two-ways.

• GUI is partly customizable.

• Release V3 supports visualization of workflows, which log history data.

• Product Structure Browser shows product structure, suppliers, effectivity,associated documents, responsible persons and other related objects.





• Customization toolkit

• Support for multiple sites to store data

• Support for distributed corporate processes

• Java client for accessing documents

4.2.4 Architecture

• Based on relational database (allows many databases)

• Three tier client-server architecture (allows many servers)

• Replication between databases

• Supports STEP on some level and CORBA

• Amount of application servers can be added later to system if necessary

• Interface between database is either DB2 CLI support or Oracle’s SQL net

• Interface between client and server is based on TCP/IP RPC

• In client sending and receiving data is capsulated into own layer

4.2.5 Environment requirements

• Works in various mainframe, UNIX and PC environments

4.2.6 Summary

EnoviaPM has some nice off-the-shelf integration with other software. Data-model hasn’t much flexibility for customisation and browser client has subset offull clients features, but otherwise there is good support for distribution. Multipleservers and databases are supported. Metadata can be distributed over separatedatabases. Replication can be done through transferring whole data at once or bytransferring only changes to save bandwidth. Environment requirements allowlots of variation when it comes to hardware.

4.3 Agile PDM

4.3.1 Background

Agile PDM is made by Agile Software, which was founded 1995. As partici-pants there were people having PDM or software backround, which includespeople from the client side of PDM. Agile has gotten financing from SiliconValley venture capitalists. Upside magazine has chosen Agile Software to beamong hot 100 private companies in year 1998.



Customers are mainly from the electronics industry having share of 90% of theinstallations. Focus isn’t in the product development process but in the supplychain, handling information publishing and proposal of changes mechanismbetween main company and its ousourced activities. As examples of customersthere is PairGain, FujiFilm, DataCard, Nokia, Metawave, Nortel and Xircom.

4.3.2 General information

Agile PDM product is made of integrated modules, and basic container for thesefunctional modules is Agile Workplace. There is Configurator, which handlesproduct configurations and related documents and BOMs. In Configurator thereis tools for creating and tracking changes and for viewing documents. There isChange Control Board for workflow definition and for approving and rejectingchanges in a way workflow defines. Administrator gives easy ways to definecustomized fields, default values and lists of possible values. There is alsographical tool for user interface customization and poss ibilities for defining userrights in detailed way. Reports is module for graphically configurating reports.Scan is for scanning document, ChangeCAST transports information to ERPsystem, import and export use and produce ASCII or Excel files for transferringdata, for example for transferring BOMs.

4.3.3 Highlights of features

• Easy configuration through parametric changes (no coding)

• User definable fields, part of user interface is custom defined through graphi-cal editor

• Wide possibilities in defining user rights and workflow

• Well implemented data change management

4.3.4 Features when it comes to distribution

• Java client

• Supports only one database

• No macro language for customization, and it seems to be that customizationthrough coding isn’t possible in practice

• Crypted transfer of data between server and client

4.3.5 Miscellaneous issues

• Fixed price policy in delivering the product

• Fixed time table policy in delivering the product



4.3.6 Architecture

Software is based on 3-tier architecture. System is running in Windows 95/NTenvironment. There is either Oracle’s or Microsoft’s database. Server is codedwith C++ and as client there is either Windows client or Java client in browser.Java client provides same functionality than Windows client. Structure of data-base is fixed, but there is reserved columns in tables which can be used for stor-ing user defined fields.

4.3.7 Summary

Although Agile has made fine product, it’s focus isn’t in the design and there isno integration with CAD systems. Through Java client there is access to serverfrom anywhere in the world, but there is only one server available for storing thedata. Focus of this product is in sharing the information in the situations ofoutsourcing, when information is published or changes are suggested to partners.

4.4 Optegra

4.4.1 Background

Optegra is made by PTC, which stands for Parametric Technology Corporation.Company was founded 1985 and has been growing ever since and producesmultiple product lines, which includes for example Pro/Engineer and CADDS.Amount of workers is 4800 and PTC is among the largest software companies inthe world. PTC acquired Computervision corporation past January.

PTC makes software for product development and information management.Over 21 000 companies worldwide have been using software produced by PTC.Specific examples of use of Optegra PDM software in Finland are implementa-tions in Nokia and ABB.

4.4.2 Features

• Support for workflow as task based solution allowing dynamical change ofdata between applications and users

• Support for project management through task definitions

• Explorer has support for animation of 3D models

• Interfaces for variety of product development, MRP and office software

• Whole life cycle management of product.

• Scanning of documents

• Searching and retrieving capabilities

• Text search through documents without opening them (for example supportfor Word and Word Perfect)



• Navigator for handling document and assembly structures

• View and markup tools for engineering documents

• Exporting of data in various dataformats

• Backup functionality (includes integration with Network back-up services)

• Interfaces to Optegra from following systems: AutoCAD, CATIA,Pro/Engineer, CADDS, MEDUSA, DesignPost and other MS-Windows ap-plications

• Configuration management provides tools for tracking changes in process ofcreating different configurations

• International character set


• Multiple databases, which can be seen logically as one to user

• Automatic replication between databases

• Automatic delivering of tasks to workers with dataobjects

• Includes assembly design tools (CAMU & Explorer) which work in real timein multiuser collaborative environment for creating, viewing and manipulat-ing model.

• API which support almost every functionality of Optegra through C-interface

• Application triggers which can start scripts and applications

• Inner messaging system

4.4.4 Architecture

• Client/Server architecture

• Object-oriented technology for product information, process definition andfor integration with other applications

• Three functional modules which can be used also independently: InformationVault, Process Management and Configuration Management

4.4.5 System requirements

• Configuration Management works in Solaris and HP-UX

• Explorer works in HP-UX, IRIX, Solaris

• Distributed vault works in Digital UNIX, HP-UX, AIX, SunOS and Solaris,IRIX (client only)



• Full Text Retrieval server works in Solaris, HP-UX and client works in Win-dows 3.11, 95 and NT

• Previous were examples of environments. In general for different modules ofOptegra there are different combinations of wide variation of operating sys-tems which are supported.

4.4.6 Summary

Optegra is for big and heavy implementations which require lots of customizing.Practically speaking there is complete control over software through API andprogrammers can control it as needed. There is also support for wide variation ofoperating systems and off-the-shelf integrations PDM related software. API isflexible is enough to be two directional to allow customizing through other pro-gramming languages using Optegra commands. In this way it is possible for ex-ample to add custom designed GUIs.

4.5 Matrix

4.5.1 Background

Matrix is developed by MatrixOne company, which sold first version of MatrixPDM system 1994. MatrixOne is fully concentrated in PDM products. Companyhas been listed among Upside Magazine’s Hot 100 Private Companies list. Cur-rent customer base is around 250 with 40 000 licenses sold. Sales offices are in15 countries.

Technia has just started selling Matrix in Finland. As references of sold systemsthere is Ericssonn and Scania from Sweden. Scania is going to have global im-plementation of Matrix.

4.5.2 Features

• Off-the-self integration with AutoCAD, Autovue, Cadra, CATIA, Imagena-tion, SAP R/3, Solid Works, ViewLogic and many others

• Digital mock-up software

• Structure management

• Workflow support, which can be directed through wizards (includes requests,orders and notification)

• BOM management

• Good view defining capabilities


• Replication between databases

• Good performance cache for data



• Object oriented user defined data model

• Java client supporting same functionality as Window client

• Documents transferred when needed or updated based on time intervals

4.5.4 Architecture

• Oracle or Objectivity as database

• 3-tier architecture

• UNIX, Windows 3.11, 95 and NT as supported operating systems

• Network support including any TCP/IP network

• Server is CORBA-compliant

4.5.5 Summary

Matrix has support for distributed work. There are multiple servers with replica-tion and with flexible datamodels. Datamodels can be even defined in a way, thatpublished and replicated version of data of local server is its subset in object ori-ented way. There is efficient cache to minimize downlaoding times. As a limita-tion there is, that Matrix works only in online mode. Customization seems to bedone in parametric way and through this control over software is limited.

4.6 Metaphase

4.6.1 Background

Metaphase is product of Metaphase Technology which is division of StructuralDynamics Research Corporation (SDRC). SDRC provides software for me-chanical design and engineering services for design, analysis, testing and manu-facturing of mechanical products. SDRC was founded 1967 and started from en-gineering consulting, but nowdays about 90% of revenue comes from softwareproducts and related services. Revenue from the year 1997 was 351 million dol-lars. Main products are mechanical design software and PDM sofware.

Current customers of Metaphase are from varied fields. Among customers areNokia, Partek, Fazer, ABB, Ericsson, Ford, Boeing and Microsoft.

4.6.2 Features

• Document management


• Workflow, including review, approval and work assignments

• Change control

• Change impact analysis



• Foreign language support: French, German, Korean and Japanese as separateproducts


• Java user interface through web browser, which is full functionality client

• MetaWeb HTML based interface to Metaphase, which contains limited waysto access and manipulate data.

• Integrator Toolkit which consists GUI tools, and APIs like operating systemAPI, user interface API, database interface API, network interface API.There is also Object Dictionary and Dynamic rules processor.

• Readily available integrations to following software: I-DEAS, Pro/Engineer,AutoCAD, FrameMaker, Mentor Graphics, SAP, Oracle Manufacturing andUnigraphics CAD

4.6.4 Architecture

• Oracle, Informix and Microsoft SQL Server as databases

• User interfaces in X/Motif, Windows and Java

• Platforms include Solaris, HP-UX, Windows NT, AIX, IRIX

• Three-tier architecture

4.6.5 Summary

Metaphase seems to be very flexible product. There is toolkit for customization,which is especially tuned towards possibilities of integration with other software.Plenty of integration solutions are available readily from the shelf. There is webclient with full functionality. There is also additional web client based onHTML, which is intended for easier access and lighter use. Regardless of thesegood sides, in available material question of simultaneous support for multipledatabases remains open.

4.7 D-Iman

4.7.1 Background

D-Iman is distributed version of Iman made by Unigraphics. Unigraphics iscompany to provide mechanical CAD related software. Software is marketedworldwide to industries in various fields, like automotive and transportation,aerospace, defence, consumer products, electronics and medical. As partnersthere is big IT companies like Digital, IBM, HP and Sun.

Iman customers include Boeing, Israel Aircraft Industries, Motor Coach Indus-tries and Phillips Components. In many cases Iman isn’t sold alone, but in samepackage with other Unigraphics software.



4.7.2 Features

• Check in and check out automatically or manually

• Motif interface

• Links can be created between data by user

• Organizational specific attributes can be created

• Administrator tool includes definitions of groups, roles, tools and sites

• Utilities for backup and recover

• Own shell for encapsulating other applications

• Support for workflow


• Multiple databases available for simultaneous use

• Both metadata and text can be distributed, sites can choose which data ispublished

• Data can be located through centralized Object Directory Services database

• Information can be replicated to other databases for quicker access

• For partner access separate Object Directory Service database can be used forsecurity reasons

• Note: only at owner site object can be modified

• Integration toolkit

• Two web clients: one for viewing documents and other for viewing andcommenting documents

4.7.4 Architecture

• Oracle as database

• Client/server architecture

• API accessible by "C"-calls

• User customized DLLs possible

• Support for following platforms: HP-UX, Solaris, IRIX, Open VMS, DigitalAlpha NT and UNIX, AIX and Windows NT



4.7.5 Summary

Iman has as distributed capabilities multiple databases where both files andmetadata can be distributed. Data can be modified only at owner site. SpecialObject Directory service on separate server can be used to control access to datefrom outside of the company. There is possibility for integration with other soft-ware, but there is lack of readily available implementations. Web interface islimited into viewing documents or viewing and commenting those through sepa-rate applets. There is also question of how well different operating systems aresupported when it comes to full functional clients. At least client with full func-tionality is available in UNIX. Architecture is Client/server, which might make itdifficult to have in future full Java client.

4.8 Summary table of PDM products

Following table contains PDM software which was addressed in this paper.Software is on columns and features are on the rows. Since mostly the case is,that it isn’t on/off situation with features, but there is variation in depth and qual-ity of implementation, there is scale used from zero to three. Zero means thatfeature isn’t implemented. One means poor implementation, two means averageimplementation and three means good implementation. However, it must benoted, that grades given in the table are rough estimates, since there has been nofirst hand experiences with the software. Mostly the impression is based onwritten material by vendor, supported by seeing some of the features in demosituations. Point of view of the table is in features, which support distribution inwidely understood context.

Feature MST 9000 Enovian PM Agile PDM

Browser client 3 2 3

Distributing DB (files) 2 2 0

Distributing DB (metadata) 2 2 0

Smart cache or replication 3 3 ?

Database options 1 2 2

Integration with CADs ? 3 1

Integration with ERP/MRP ? 3 3

API 3 3 1

Macro language 2 0 0

Flexibility of datamodel 2 1 2

Crypting transferred data 2 ? 2



Server platforms 2 3 1

Client platforms 2 3 1

3-tier architecture Yes Yes Yes

Access right definitions 2 2 3

Out-of-the-box functionality 2 3 3

Parametric customization 2 1 3

Feature Optegra Matrix Metaphase D-Iman

Browser client 0 3 3 2

Distributing DB (files) 2 2 ? 2

Distributing DB (metadata) ? 2 ? 2

Smart cache or replication ? 3 ? ?

Database options 2 2 2 1

Integration with CADs 3 3 3 2

Integration with ERP/MRP 3 3 3 2

API 3 1 3 3

Macro language ? 0 ? ?

Flexibility of datamodel ? 3 ? 2

Crypting transferred data ? ? ? ?

Server platforms 2 3 2 3

Client platforms 2 3 2 3

3-tier architecture No Yes Yes No

Access right definitions 2 3 ? 2

Out-of-the-box functionality 1 2 ? ?

Parametric customization 3 3 ? ?



4.9 Guidelines for interpreting summary table

These guidelines are meant to be as help to interpret given scale, which is used toestimate the feature in the table.

4.9.1 Browser client

Zero means there is no browser based client. One means there is poor imple-mentation, which might for example be implementation by using HTML. Two isaverage implementation based on Java, providing subset of PDM functionality ofthe primary client. Three refers to Java implementation, which provides fullfunctionality of primary client.

4.9.2 Distributing DB (files)

Two as a grade is mostly used to mean, that it is possible to distribute files intodifferent servers. Zero means that PDM software supports only one server. Toachieve grade three, it would require support for off-line working and dealingintelligently with the situation, when same files have been edited simultaneouslyat different places.

4.9.3 Distributing DB (metadata)

Two as a grade is mostly used to mean, that it is possible to distribute metadatainto different servers. Zero means that PDM software supports only one server.To achieve grade three, it would require support for off-line working and dealingintelligently with the situation, when metadata needs to be merged when goingback on-line. Currently it seems to be, that no vendor provides this type of func-tionality.

4.9.4 Smart cache or replication

Smart cache or replication means, that there is taken steps to optimize operationeither through using cache or replication in smart way. Smart cache might mean,that client has local cache which is searched through first. Smart replicationmight mean, that only changed data is transferred when requested. Since algo-rithms are difficult to estimate without benchmarking, every known attempt isgraded as three, if there is no reason to suspect, that implementation is poor.

4.9.5 Database options

This simply refers to amount of database servers which is supported. If there isknown support for one database, grade one is given. If there is support for multi-ple databases, there is grade two. If there would be support for both relationaland object databases, it had been graded as three.

4.9.6 Integration with CADs

Three is for close integration with multiple CADs. Two is for the case, when in-tegration or number of CADs is very limited. One is for the case, when PDM



system is mostly for storing CAD documents like any other files. Getting one re-fers to minimal support for customization through API.

4.9.7 Integration with ERP/MRP

Three is for close integration with multiple ERP/MRPs. Two is for the case,when integration or number of ERP/MRPs is very limited. For getting two orthree, it also requires, that these integration is available off-the-shelf, withoutconsiderable amount of extra work.

4.9.8 API

For getting three as a grade for API, it requires that full functionality of PDMprogram is accessible through API.

4.9.9 Macro language

If there is no macro language available, grading is zero. Getting one refers to thatthere is macro language available, through which some customization can bedone. If macro language is powerfull enough to be used for calling operatingsystem functions, grading two is given. If there would be also visual program-ming environment, grade three would be given.

4.9.10 Flexibility of datamodel

If datamodel can be in some way edited through changing parameters, grade oneis given. If for example new fields can be added through changing parametres,grade two is given. If new objects can be added and linked in customizable way,grade three is given.

4.9.11 Crypting transferred data

If PDM product is known to have internal crypting of transferred data betweenclient and server, grade two is given. If there is no support for this, grade zero isgiven.

4.9.12 Server platforms

If server can be installed in wide variation of operating systems, grade three isgiven. If there is more than one operating systems available, grading is two.

4.9.13 Client platforms

If client can be used in wide variation of operating systems, grade three is given.If there is more than one operating systems available, grading is two. This grad-ing doesn’t tell anything about existence of browser client.

4.9.14 3-tier architecture

If there is 3-tier architecture used, grade is ’Yes’. For traditional client server ar-chitecture grading is ’No’.



4.9.15 Access right definitions

As default grade two is given. If there is exceptionally flexible implementation,grade three is given.

4.9.16 Out-of-the-box-functionality

If PDM software is ready for use after installation with minor configuration,grade three is given. If there needs to be done lots of parametrization, grade twois given. If there needs to be done coding, grade one is given.

4.9.17 Parametric customization

If there is plenty of possibilities for customization through parameterization, likeconsidering for example access rights, datamodel and user interface, grade threeis given. If there is somewhat less possibilities, for example user interface isn’tcustomizable through parameterization, grade two is given. If there isn’t so muchpossibilities, grade one is given.

4.10 Summary of PDM products

This collection of software could be seen as good sample of overall situation.There is older software like Optegra and newer like Matrix. Difference shows inimplementation techniques. Optegra uses for example older client/server archi-tecture, when Matrix is three-tier style of the end of 90s. Difference shows inflexibility to support distribution, for example through browser. Another issue isreplication of data between distributed databases, which easily requires more in-telligence than what traditional database can provide on its own.

Another division between older and newer software is in ways to implementcustomization. There has appeared more weight on customization through pa-rameterization that through coding. This results faster and easier installation pro-cess. Naturally there has been trade off between customization power and easi-ness, but there is market trend for off-the-shelf products which fit into specificmarket segment. Agile is following this strategy and 90% of its current custom-ers are from electronics industry. Also, Agile has shifted the focus from designto state after design, where product data is communicated for example to con-tract manufacturers.

At the same time time less coding is needed, there has become available ways tocustomize freely datamodel of database. Matrix is one of the leading products inthis direction to provide general purpose PDM. In matrix’s solution user can de-fine freely object orientated datamodel, connections between objects and pa-rameters.



Security concerns through use of network and business model of extended enter-prises are visible in products. As ways to meet the challenge there is widely usedcrypting of transferred data. Special attention is also paid to flexible definition ofuser rights, so that selected part of the data can be shared with partner corpora-tions. One way to provide extra security is visible in D-Imans way to connectother corporations to own company’s datavault through separate data directoryserver, which has pointers only to allowed subset of data.

All software reviewed supports distribution in some way, but there isn’t oneproduct over others. Products have strengths with some features and weaknesseswith other features. One product can’t be pointed and recommended, since us-ability of product naturally doesn’t depend only in its distribution features in dis-tributed work, but also about how well it does support the specific work in spe-cific environment. Like, important things are for example specific platform andcompatibility issues with other software. Products have also been tuned to per-form optimally in different tasks. Sometimes added functionalities, like for ex-ample support for workflow might be important.

However, one word of caution can be said. Solutions which support only oneserver and/or are implemented in client/server architecture, are candidates forfailing to fill the needs of future through inflexibility of basic design choices.Also, newer the product is, as default there is, that its inner implementation ar-chitecture supports naturally distribution.

5. LIST OF FEATURES IN IDEAL DISTRIBUTED PDM PRODUCT

Following list of features is made using features of existing systems as startingpoint. Ideal features come close to existing features, which rises question, ifPDM systems are close to their full potential as those are currently defined.

• Customization environment which contains graphical GUI design. Easy waysto add menus and buttons and replace existing methods.

• Macro language, through which is access to dataobjects of PDM system,which contains both attributes and methods. Access to operating system callsand easy interfaces to other software products.

• Powerful API

• Full functionality through browser client

• Multiple platform support for client and server

• Full distribution of data and metadata

• Optimized ways to transfer data

• Plenty of off-the-shelf integration solutions with other software



• Plenty of parametric based customization, which includes datamodel and ac-cess rights.

• Possibility to dynamically change datamodel and workflow.

• Use of strong cryptography.

• Basic functionalities of PDM software

• Offline functionality



6. DISTRIBUTION ARCHITECTURES

Question about if PDM system is distributed or not, doesn’t have simple answerof yes or no, but there are different approaches for achieving goal of distributionand different depth at which approach is followed.

Basic entities which can be distributed are data, metadata and users. Data refersin practice to various files, which can be for example CAD drawings, text filesand images. Metadata is information about files, like information about accessrights, creator of file, date of changes etc. Metadata covers also structural infor-mation and additional file independent information, which can be often conven-iently stored in relational database. Data is about bigger blocks of information.Metadata is about small pieces of information, which has structural relationshipwith each others. Users refer to people who are using the system, viewing ormanaging data.

Distribution can be also about distributing software components, but distributionof data and usage gives most fundamental impact to distribution concept, andthrough this information and usage are selected to form point of view of obser-vation. Any combination of distribution of basic entities is possible, althoughgenerally it is, that there is more requirements for mobility of users than for mo-bility of information storage.

In most simple scenario all of the information is stored in one place, in one data-base, but usage is distributed. Users can view and change information throughclients from various physical locations. There can be either operating system de-pendent clients and browser based clients. Operating system based clients func-tion more efficiently and smoothly, but normally amount of supported operatingsystems is limited. Browser based clients are more universal, based on technol-ogy provided by Microsoft or Netscape, but their downside is slower executionof code, and possibly limited functionality, when compared with operating sys-tem clients. This distribution scenario works very well in LAN, but for the longdistance clients bandwidth of network can cause problems. There are also ques-tion of how trustworthy is the operation of network, since there is required con-tinuous on-line connection for any information retrieval or change of the infor-mation. For local distribution this alternative might be the best, if needs of thefuture are also limited, since centered solution is cheaper and easier to adminis-trate.



As second scenario there is having multiple servers, but in a way, that only datais distributed to different servers and keeping metadata on one server. This solu-tions requires also continuous on-line connection, but bandwidth requirementsare much smaller, since metadata transmission doesn’t include big chunks ofdata. Files can be kept on separate servers organized in a way, that if there aretwo physically distant offices, each has own server, which contains those fileswhich are used locally. This way there is minimal need for transferring files overWAN or Internet and it is done only when needed. To improve performancefurther, each server can have cache for files of another server and retrieve infor-mation from cache, if metadata shows that files haven’t changed since last re-trieval. Another alternative, if cache is not preferred, is to copy "remote" filesinto local database, but only on the moment when those are retrieved for the firsttime or after change. In practice there isn’t so big difference between cached orremote copies in local database.

Third basic scenario doesn’t distribute only data, but also metadata into separateservers. This means, that there is copy of metadata on every server; otherwise itwould be needed to check during every request on every server, if metadata haschanged, which isn’t practical solution. However, this alternative causes problemof concurrent changes of metadata on different servers: what happens if samemetadata is changed simultaneously on different servers? Since this would causerisk of inconsistencies sooner or later, usually metadata is attached with owner-ship information, which tells who can change metadata. Ownership informationis configured in a way, that same piece of metadata can be changed only on spe-cific server, which takes care of concurrent attempts to change information bydenying such attempts. Metadata is then replicated to other servers which haveonly reading rights for it. Updates of metadata can be done in real time or aschunks once a day.

Current PDM systems belong into one or more of the classes presented above. Itmeans, that it isn’t possible to reach in this framework true distribution. Truedistribution could be defined by allowing changing any information at any serveror client, and at the same time allowing any interruptions into connections atrandom intervals and synchronizing the system when servers get back online byhaving intelligent algorithms for handling inconsistencies. In everyday use thiscould provide flexibility, especially if it can be known, that probability of occur-rence of inconsistencies is low, and even in situation when it would happen,there would be recovery mechanism available. Of course, if needed, there couldbe defined access rights in a way which would prevent inconsistencies totally, orlimit those into non-core areas.



7. CONCEPTS FOR DISTRIBUTED PDM

7.1 Introduction

This section is for presenting concepts about distributed PDM environment.Level of description is on high level, which means, that there is no details pre-sented here which are important in practical PDM implementations of the com-panies. Level of description is also such, that no sides are taken with technologi-cal issues, how presented ideas could be implemented. As the situation is, theseconcepts don’t provide solutions, don’t tell about how to optimize system andmake compromises. In general there is no hint of preferences about the impor-tance of individual concepts. What is presented here, is general level framework,which can be used to understand PDM systems, one notation which can be usedfor comparison of different systems. It is also possible to use presented conceptsfor making high level sketches of planned implementations or make require-ments for system to be purchased. Presented framework is not claimed to becomplete, and it is not tested to model existing PDM system.

Individual concepts itself are very simple and clear, which has been also as agoal in choosing those. However, combinations of these and taking descriptionsto more detailed level introduce complexity which provides alternative solutions,which are strong from some perspective and weak from some other perspective.Probably there isn’t solution which is good from all perspectives. For example, itis difficult to combine hierarchy, configurations and versioning into good us-ability; rules of how changes of one component affect to other components canbecome quite complicated, difficult to understand and learn.

Concepts have been tried to choose in a way, that content isn’t overlapping witheach others. Idea is, that concepts could be like independent dimensions, whichcan be combined in unlimited way. There is no clashes, when any number ofconcepts are chosen to model a system. This follows ideas presented in pro-ceedings ’Managing Design Data’ article of IEEE from the year 1996.

Concepts are presented shortly as a list in following paragraphs.

7.2 Data

Data is actual information which is stored in PDM system. It can be either filesor more structured information, like in object or relational database table form.Data is that actual content which is wanted to be stored and managed using PDMsystem. Data can be seen as smallest possible units which are managed throughsystem, it is target of operations like viewing and updating. Depending on per-spective, that unit can be for example one file, which is like black box with un-known content, or it can be for example known datafield in the table.



7.3 Metadata

Metadata is also data to be stored into system, and difference between it and datadefined in previous paragprah is that metadata defines other stored information.It can be for example simple data like creator of the file or date of the change.On the other hand it can be more complex data which defines relationships be-tween different dataunits. It can for example be information about hierarchicalrelationship between dataunits. Metadata can be seen as data which gives se-mantics or as something which glues together individual pieces of information.

In following paragraphs subclasses of metadata is given. Subclasses can befreely added based on needs. Subclasses are tried to choose in a way, that thosewould present as well as possible main trends in current PDM implementations.Trivial type of metadata subclasses aren’t presented. As examples are length ofthe file or date of creation, instead, more structural or functional type of meta-data is presented.

7.3.1 Connection

Connection is glue between otherwise separate data units. If data is symbolizedwith circles, connection can be symbolized with various types of lines and ar-rows connecting circles.

There can be defined different types of connections. One can be for example’link’ type connection, that some other data has something to do with this otherdata in a way which isn’t specified strictly, but which can be for example de-scribed with a couple of words of natural language.

As traditional connection there is ’contain’ type of connection. This means, thatone dataunit contains another in a way, that another can be seen as a parent andanother as a child to form tree like structures.

As another traditional connection there is ’alternative’ type of connection, whichcan be used to describe different configuration possibilities. For example, dataabout various compatible lightbulbs can be connected through ’alternative’ con-nection to lightbulb socket data.

Yet as one type of connection there is ’reason’ connection meaning, that somedata in one place can be reason for some data elsewhere. Reason can be de-scribed by natural language.



7.3.2 Version

Versioning tells about changes in data. New and past data are recognized by ver-sioning data, which tells which version is newest and about order in whichchanges where made. Versioning isn’t necessary linear process, where next ver-sion is always based on recent version, but also older version can be taken to bebase for improvement and to become newest version. Defining use and rules forversioning is based on company processes and application area.

7.3.3 Release

Release tells that something is complete, for example some design might beready for production and certain versions are marked to be part of release. At thesame time there might be different releases for different purposes. Issue of re-lease might become complicated, if there are detailed rules how release is formedfrom all available versions.

7.3.4 Access data

Access becomes especially important in distributed system. Management of ac-cess information has potential for complexity, if it isn’t one authority who haspower to make all decisions, but there are several negotiating authorities. Accessis information about who can have rights doing what and when. For example, forsome person there can be rights for viewing something, but not for changing it.Rights might be also defined on level of group. Access isn’t only about companypolicy and reflection of person’s position in organization, but access is tool formaintaining consistency in distributed PDM system.

7.3.5 Place

Place is new element, when compared to non-distributed PDM system. It ex-presses location of information, into which data vault information is located.Place is important parameter for defining of operations, access information andrules. If some information is existing only in one data vault, that simplifies op-erations. But, if that same information is existing simultaneously on multipledata vaults, that causes complexity into system functionality through taking careof possibility of simultaneously inconsistent operations and recovery after suchsituation.

7.4 System data

System data is something which isn’t that primary data which is wanted to bestored into system, but it is rather to be seen as data which is needed in main-taining the system and base for defining system’s functionality. System data canbe for example locking information for maintaining consistency, or informationabout rules of how to arrange versioning changes or rules about defining whichare allowed operations.



7.4.1 Lock data

Any information can be locked. Locking is about limiting temporarily opera-tions, which can cause inconsistencies. Usually locking is against simultaneouschanges and keeping at the same time rights for viewing. Locking is low leveloperation against integrity threats, which is usually managed by system withoutuser intervention. Lock is status type of data, which is checked before operationsand after which suitable action is taken.

7.4.2 Transaction data

Transaction data is for managing operations in a way, that those can be executedin atomic way. After transaction operation is either executed successfully andchanges to database are made, or, if there is failure, target of operation is givenits state before operation. Simple updating of a field is easily atomic operation,but sometimes there are operations, which are formed by chain of operations,and in these situations transactional information is essential.

7.4.3 Time stamps

Time is essential concept in distributed situation. Most challenging problem ofsimultaneous overlapping operations occurs in situation, when operations aredone off-line. In case of on-line operations, reasonably accurate synchronizationof clocks in separate but connected PDM systems is available. Concepts of si-multaneous and non-simultaneous operations are defined and observed by usingtime stamping.

For example, reading can be perfectly safe operation in distributed system.Changes can also be safe in situations where data vault is distributed with respectto both data and metadata. Trivial solution is to define only one server on whichspecific dataobjects can be changed and then other servers are only for reading.More sophisticated solutions would allow changing of almost everything onevery server, although changes would be simultaneous and there would be tem-porarily closed network connections. This would require intelligent merge op-eration after network connection would be functioning again. Managing simulta-neous delete and change of same object could be for example defined in a way,that change is stronger and that it would renew existence of object in merge onall servers. Managing simultaneous adding of variations would be conceptuallytrivial and consistent: after merge each separate added variation would be up-dated on every server.

7.4.4 Rules

Rules tell what operations are allowed and what operations are not, and underwhich conditions and for which participants. As simplest rules can be easilyformulated constraints for changes. Rules are close to access rights, but are atthe same time more general, and can be seen as interpretation of access rights,which results rules to be metametadata, metadata of access information.



7.4.5 Operations

Operations define specified functionality of the system and reflect the require-ments. Operations are commands users are giving with various parameters. Op-erations are conditional based on rules. As examples of commands are adding offile and changing content of specific user accessable metadata. Operations don’tinclude user interfaces, but exist on higher level, and implementation of user in-terface is independent of the operations. On the other hand, operations includehow system data is changed. Content of operations can be very complex, and inPDM system implementation it is existing in a form of executable code. Opera-tions are essentially instructions for accomplishing various tasks.

7.4.6 Consequences

Consequences are close relatives to operations. Consequences are specific op-erations resulted by state of system filling given conditions. Consequences areoften following operations performed by user or responses of a system tochanges in its environment. Consequences can be seen as instructions for systemhow to react in different situations. Another word to describe them would betrigger.

7.5 Observations

It seems to be, that boundaries between these three classes of data aren’t strictlydefined and there is room for interpretation. Especially there might be temptationto move things from metadata class into data class, and from system data classinto metadata class. However, this shouldn’t be a problem, but when makinganalysis of specific situation, criteria of classification can be accommodatedbased on situation and perspective of analysis.

When this classification is applied to real life situations, other concepts containvarious combinations of defined information classes. For example, there can bemodel of a product, which contains different alternatives for realization. For pro-duction of one individual one release is chosen. Concept of ’model’ in this con-text is made of data and metadata.

This framework didn’t change the fundamentals, when compared with situationwhen there is no distribution. The difference on level of framework is introduc-tion of time and place, which are essential in situations of simultaneous opera-tions of distributed nature. Situation is such, that distribution shows itself on theside of rules, operations and consequences. If these three are to be summarized,change is on the side of usage policy and system behavior, which needs to be de-fined specifically for each application area, although there probably are generalpatterns which are suitable almost for every area.



If framework is visualized, it is forming tree structure, having information on theroot. Data, metadata and system data are children to root. As grandchildren thereare connection, version, release, access data, place, lock data, transactional data,time stamps, rules, operations and consequences. This framework is not meant tobe rigid and complete, and new concepts can be introduced added on any level.In this framework PDM system can be seen as strings of bits, each string pre-senting one server including data vault. Point of view of observation is staticseeing system as having discrete nature.

8. TRENDS IN PDM

PDM market seems to be in state of steady growing having approximate rate of18% a year. CIMdata’s estimate is, that the value of the market exceeds 1.3 bil-lion dollars in the end of 1998. All of the big players of market have less than10% share of it. There has been consolidations of bigger companies, like PTCacquiring Computer Vision in the end of 1997. On the other hand, new vendorshave entered market with specialized solutions for the smaller companies. Tradi-tionally PDM market has been about big companies selling software for evenbigger companies, but now smaller vendors and clients are entering the market.

Market is segmenting and products are getting more specialized, which makesneed for customizing smaller. Installation of the software can be quicker andthere already is vendors, who offer fixed price installations with minor customi-zations. For example Matrix and Agile PDM packages are sold in this way.

New features are entering PDM applications, like features which support notonly design phase, but give support for the management of the whole life cycleof the product. On the other hand specialized products are entering selectedphase of the life cycle of the product, like for example manufacturing or aftersales.

Big investments are made especially by automotive, electronics and aerospacecompanies and building industry of complex and expensive projects.

PDM software as it is, isn’t enough to satisfy PDM needs of companies. Rather itis going to be, that the required functionality isn’t to be found in one product, butother software needs to be integrated into PDM system. For example projectmanagement and MRP can be this kind of applications.

On the other hand, at the same time extra functionalities are being build intoPDM software, software on the other field is in the process to contain morefunctionality traditionally seen in PDM applications, like for example documentmanagement in ERP or CAD software.



PDM software is continuing to be integrated with other applications. PDM prod-uct can become one intelligent distributed datavault providing various services,which can be accessed through other applications, which provide the the actualuser interface. Focus will shift to PDM server and its interfaces and services, andother companies can provide different clients for different purposes. Currentphase of development in integration is going on between PDM and ERP.

When it comes to virtual corporations, there is seen potential in combination ofweb and PDM. Inside bigger corporations product information can be sharedover geographical distances through new distributed functionalities in PDMproducts. Through trend of outsourcing less critical activities, PDM can be alsoshared between company and its contract manufacturers. Browser interface isbecoming standard in PDM software and sophisticated multiserver solutions areunder development.

9. SHIFT FROM LOCAL TO GLOBAL PDM

Local PDM here means PDM system of a local department of a bigger companyor whole PDM system of smaller company. Global PDM means either havingPDM system which covers geographically separate departments of one companyor PDM system covering virtual enterprise formed of independent companies.

Theoretically answer could be to select one of the modern PDM products con-taining distributed features and setting up the system. However, inside one com-pany there can be through historical reasons PDM systems which are difficultand expensive to replace at once. Even if this could be done, there is this anothersituation of virtual enterprise, where independent companies can come and go.So, there is unlikely existing situation, where one technological solution couldbe freely chosen.

If there isn’t possibility for tight integration, more loose approach can be chosen.This can mean, that data can be made accessible through clients which have suit-able access rights, like for example through browser client. Or, product data ofone system could be converted into standard form, transferred to the other placeand converted into other system. There can be existing converter available or itcan be possible to customize one. Or, some data like files can be taken out of thesystem without full metadata and transferred as it is.

It can be also acceptable, that not all the parties are capable to connect to PDMsystems of each others, but there can be separate "islands" which have compati-ble PDM solution.

It is difficult to sketch solution in general level for global PDM, since there isexisting so many different environments, their combinations, needs and parties,that it seems to be impossible to find general solution. Rather it can be, that im-plementing global PDM is case specific problem, which has its own unique so-lution. If ultimate solution isn’t find, there can be solutions which are acceptablecompromises.



10. PDM MATERIAL IN INTERNET

Here is short introduction to sites which provide information about PDM. Thereis given URL with short introduction of who is providing information and whatis the content of site.

10.1 Information sites

http://www.cimdata.com/

• Origin: CIMdata Inc

• Content: Articles, publications, links, industry events, conferences

http://www.pdmic.com/

• Origin: Product Data Management Information Center

• Content: Articles, discussion, links, publications, seminars, conferences

http://www.pdmic.com/IPDMUG/

• Origin: International Product Data Management Users Group

• Content: Articles, discussion, surveys, glossary

http://199.6.44.126/

• Origin: Kalthoff International

• Content: Conferences, Press releases, Industry resources (coming)

http://www.penton.com/cae

• Origin: Computer Aided Engineering magazine

• Content: Articles about CAD/CAM/CAE/PDM

http://www.cimworld.com/

• Origin: Collaborating Design and Manufacturing professionals

• Content: Links, reports, white papers, industry events, consulting

10.2 Linklists

http://personal.eunet.fi/pp/koivula/pdm-link.html

• Origin: consultant Harri Koivula

• Content: PDM vendors, STEP and other standards, STEP tools, PDM infor-mation sources



http://www.rdm.iao.fhg.de/engineering/edm/links.html

• Origin: Fraunhofer-Institut für Arbeitswirtschaft und Organisation

• Content: Miscalleneous links to general information sources and to PDMsoftware homepages

http://www.vtt.fi/cic/links/pdm.html

• Origin: VTT

• Content: Links to vendors of PDM software

http://www.sherpa.com/pdm/marketinfo.html

• Origin: Sherpa Corporation

• Content: Links to corporate and university information sources and to someFAQs

http://www.cs.hut.fi/~mam/Tik-86.140-links.html

• Origin: TKK

• Content: Links to Computer-Integrated Enterprise material, which includesresearch projects, frameworks, enterprise modeling, process modeling, prod-uct modeling, PDM, document management, Integration tools

10.3 Articles

http://www.edsug.com/publications/impact/pdm/real_issue.html

• Origin: Unigraphics

• Content: Information for purchasing PDM software

http://www.vtt.fi/tte/samba/projects/tuotetieto/index.htm

• Origin: VTT

• Content: Slides of product information management training

http://www.mvd.chalmers.se/~pikosz/research/NordDesign96/pm96.fm.html

• Origin: Chalmers University of Technology

• Content: About PDM in product development process

http://www.inreality.fi/IIR-esitys-overhead/sld001.htm

• Origin: InReality Finland Oy

• Content: Slides about PDM and XML



10.4 PDM sellers in Finland

http://www.ibm.fi/index.html

• Company: IBM

• Products: EnovianPM

http://www.eds.fi/unigraphics.html

• Company: Unigraphics

• Products: IMAN

http://www.cmd.fi/index.htm

• Company: CMD

• Products: Agile, Optegra, DOCS Open

http://www.enator.fi/yksikot/tuohall.htm

• Company: Enator

• Products: Optegra

http://www.modultek.fi/

• Company: Modultek

• Products: MST 9000

http://www.technia.se/

• Company: Technia

• Products: Matrix PDM System

http://www.ideal.fi/

• Company: Ideal Engineering

• Products: Metaphase Enterprise