Objects and interfaces

PDM Object Model and STEP.

In PDM as in any other application area, it is of vital importance to define all data objects and the relations between these, verbally as well as in an Object Model. If this is done and all the Companies within the Extended Enterprise with their Partners agree to such a Common Object Model or parts of it, it is easy to create a data base and the necessary interfaces. 

The Object Model describes and defines how the engineers see their product and this is extremely important!

An Object Model should live and be intact as long as the product (Product Class) lives. For products like cars, trucks, aircrafts, washing machine, dishwasher etc., the Object Model should be stable for several decades. This implies, normally,  that the life span of an Object Model by far surpasses the life of any computer system that will feed the databases based on such an Object Model. That is, if it is done right!

This also implies that any PDM project should start with the definition of an Object Model!   

When you have a change of technique in a product like when mechanical calculators were replaced by electronic calculators, a new Object Model would be needed. However the cars, trucks and aircrafts have not changed very much in principle build-up over the last 50 years or so. A stable Object Model should do the trick!

There is one very important International Standard in existence: ISO 10303 AP 214 also called STEP for Automotive Engineering (cars, trucks, construction machines etc.). It was released in March 2001 and contains some 3500 pages. It has since then been revised in 2010. However, it still isn’t enough and at the same time, it is too much. For an Extended Enterprise like the one I have described, it is crucial to have an Object Model of their own. The Company version should conform with the AP214 where applicable. But it may also contain one or two things that AP214 does not handle.

Volvo had over a period of 3 years, until 1998, created what they call a Logical Platform (version 3.2) with a description. This is the Volvo Object Model as defined in The Common Volvo PDM Project (while it existed – see logo). It was an attempt to include things that AP214 did not foresee. The Volvo PDM Project was never implemented as any specific PDM application. The project died due to too many political power conflicts, top executives involvement and lack of real understanding of the problems at hand – a quite common scenario unfortunately. The Logical Platform was never quite finished but it may serve as a valuable start for others, since so much work and good intentions were worked into this document.  

PDM Applications implemented without conformity with such a Logical Platform or similar will be just a local installation with no guarantee that data can be exchanged between different PDM applications. The Volvo Logical Platform is not secret – the more it is used and the more people and projects are using it, the better!

AP214 may be treated as a data exchange format. However, it is intended as a base for developing databases.  It is used for just data exchange purposes from time to time. But, it is also be used to define and to customize PDM databases – a more sophisticated use of this standard that was developed during several years with lots of good thinking. AP214 is the result of political struggles but it is still a good base for the future, global PDM applications.

Integration and Application Interfaces.

Large Groups tend to buy and sell companies. It is likely that we will get more companies in the Group and that we will have very close cooperation with some Partners who will develop and manufacture parts of our Products. We cannot expect that these new Companies will take the costs for switching to the applications used by the rest of the Group. What is important is that the new companies can interface to the (PDM) applications commonly used. The inter-communication of information is what is critical! 

Let us take a few examples: 

The ”Hub” Plants shall manufacture Products from several Product Companies. These Product Companies may have two or three different PDM applications. If they had had the same Product Definition (i e same Object Model) it should be possible to transfer files to the different Plants’ MRP applications in a way so that the Plants can easily update the information and data in their databases. However, it may still be possible to transform the data used in one Company and transfer it the the other Company’s PDM application etc. 
The different Product Companies have disparate CAD applications, of course. However, it is possible to transform the drawings in any CAD application to a common raster format and make these available across the Group including their Partners. It is also possible to transform a Geometric Model in one CAD application to a neutral format such as IGES or STEP and transfer this to another CAD application where it is ”imported”.

Since we have Parts developed all over the Group and these are used in other Products than they were originally intended for, it will be necessary to have an application for DMU (Digital Mock-up) or Virtual Product  separated from any of the existing CAD applications. It is wise to acquire an application which can handle tessellated or faceted geometric models from any CAD application and that will have a number of third-party vendors for applications using such models.

When you study the model shown above, it becomes apparent that It is crucial to define all data that shall be transferred between databases and applications as such and al the relations between these data as well as data that shall be used across several applications.
STEP is crucial to global industries working as an Extended Enterprise. 

 The Figure: Relations between PDM – CAD and Virtual Product applications – or rather disciplines. This is how it should work:

  • The CAD application has the ability to create Geometric Models, preferable solids, from which drawings can be derived and completed. We have of course more than one CAD application within the Extended Enterprise that have this ability. 
  • The Geometric models are transformed to tessellated models and stored in a database that can be accessed by the Virtual Product application. 
  • The Geometric Model is also defined regarding position and orientation in relation to a local coordination system that in turn is defined in relation to a global coordination system for the complete Product. The coordinates for the Part are recorded in the PDM application as attributes to the Product Structure Record. It may be necessary to transform data from the different PDM applications when there are more than one at hand or when the Virtual Product application requires the information to be available in a specific way. 
  • This information is available to the Virtual Product application and is used to create the Virtual Product Model that may be displayed on the screen for visualization or used for kinematics and other usages. 

There are several applications available on the market that can handle Virtual Products, complete or in part, and more will come. This is of course a simplified explanation of how it may be handled. However, it does show that in most cases it is impractical to try to solve the Virtual Product within a CAD-application. 

Below is a conceptual model of relations between different functions of a typical PDM application. The model is considerably simplified. A more detailed version may be found under Product Structure and ECN & Effectivity.