Friday, July 1, 2011

PDMS vs PDS




PDMS / PDS Technical Comparison

Management Overview

This document is technical comparison of Cadcentre’s PDMS product against Intergraph’s PDS.

The comparison focuses on the following areas :

• Database Organisation and Administration
• Modelling
• 3D Clash Detection
• Drawing and Isometric Production
• Reporting
• Customisation
• General Functionality

Although PDMS and PDS appear to have similar functionality the structure of the two systems is basically very different. PDMS has important technical advantages in several key areas making it a more productive system and allowing true concurrent engineering methods.

Companies which have experience of both PDMS and PDS estimate that between 20% and 40% more user accesses are required to complete the same project using PDS. For example, a project which would require 10 licenses of PDMS might require 12 to 14 licenses of PDS.

Database Organisation and Administration

(Bold refers to PDMS)
(Italic refers to PDS)

PDMS is based on a multi-discipline database architecture. Although the database is proprietary it is open and can be accessed easily using the toolkits provided. The underlying file structure of the PDMS database is invisible to the user who simply navigates around a hierarchical project structure.

PDS holds information in model files. The .dgn files hold the graphical information. Associated with this are the .drv files with some attribute data and is the link from the graphical files to the oracle database. The system uses standard SQL links to Oracle to write and read information from the database.




Each application must have its own reference file and there is a maximum of 256 reference files (may have been increased recently) available at any one time. The performance of the graphics manipulation drops off if the file becomes larger than 10MB. This equates to about 70 pipes, 20/30 equipment items or about 4 pipe racks.

On large projects the data must be split down into many files. By discipline, by area and by sub area (when the files become too large). Users on large projects cannot add in every reference file to work on because of the file limit and speed limit. Adding 256 reference files severely impairs performance. So most users have had to create utilities that look at each reference file and see if any data in the file appears in the 3D envelope they wish to work in. This utility is very time consuming when entering the system but does speed up (relatively) the response once the user has entered the system.

Again on large projects it is impossible to do drawings or clash runs on the whole project because the maximum number of reference files is usually exceeded.
There is no internal data management in PDS. Access permission to files is done at an operating system level.

PDMS has internal data access control as well as external.
On smaller projects which are multi-disciplined the user can not swap between different disciplines in the same reference file. The application ware (GUI) between different disciplines is also different. The user must actually come out and re-enter the system if swapping between disciplines which wastes time.

The PDMS database includes all disciplines. The major advantage being that the interference checking between those disciplines will not have errors due to stepped data release.

The link to the oracle database is via user data, stored (hidden) with the element. Items can be named the same. Therefore there is no integrity of data. The .drv file is an ASCII file and can actually be edited outside of the system using a standard editor.

In PDMS the attribute data is stored in the same database as the graphical information and is protected from the user by the applications.

Any item in the database cannot be referenced by its name. Every item must be accessed graphically. If a valve description changes in PDS the user must first find out on which reference file each valve exists. He must then go into the relevant application and access each valve individually and graphically to change the data! There is no mass data manipulation.

When a piping item is placed graphically in a model file the information about its details are extracted from look up tables and modelled from a program called EDEN with primitives in the Microstation drawing (model file so not referenced as in PDMS).


 If the piping item information is changed it does not automatically update the information in the reference file as it was copied. Therefore the user must follow the above procedure when updates in the catalogue occur. The Eden catalogue modelling process is clumsy to trace, no debugger is available, and programmer skills for catalogue work are necessary.

As each item’s information is copied down individually it makes for large reference files for relatively small amounts of data when compared to PDMS.

With single data entry and the integrated database approach, PDMS stores the project data very efficiently. Databases produced by PDMS are up to 70% smaller than a PDS database for the same project which results in performance gains.

Specifications are based on look-up tables. The pipe size is stored in a range from - to which a reference to tables and an Eden program for this range. Only one gasket type/thickness table per Spec. Is allowed. Only one bolting type (stud/machine) per range is allowed, individual bolting must be overwritten by the user in design. Part of the specification default setting is stored on layer 64 of the Microstation model file, so if you want to change your defaults (e.g. Bend/Elbow for sketch line routing) you have to load a different model file.

PDMS has a more complete model of the parts required for the BOM and can also handle mixed bolt situations. This means that the BOMs produced are more accurate than in PDS.

No insulation specification with thickness table available ( this may be available in the latest version ).

The oracle database is a standard multiwrite relational database. Once information is written to that database, it is impossible to undo that write or quit out of a work session. If the graphics and oracle databases get out of synchronization it is very difficult to reinstate the linkages between the two separate file systems. Many PDS customers regularly experience database linkage corruptions because of these two separate systems which the project administration staff has to repair.

PDMS has a single integrated database with no link corruption problems.

Modelling

PDS can design in full colour shade but it is a static image. The user cannot then rotate or zoom the image. Most users work in wireline with no shading. This might change with the latest hardware. Piping input is done with sketchline routing (system line only) and automatic placement of elbows, bends, tees and reducers afterwards. Pipe editing e.g. deleting a 1 mm gap, must be done with the cursor. Deleting of pipe and new input is often necessary if changes are too complex (as in sloped lines).

PDMS has very high performance dynamic shading allowing users to work in shaded mode even with large models.

It is not possible to have different levels of representation in PDS, i.e. centre-line, access space and obstruction. More importantly insulation is not modelled. It is only a reference on the pipe.

The PDMS catalogue is design to handle several levels of representation for every component.

Tube is modelled with cylinders and not implied. If you wish to insert a piping item in a line the (graphical) cylinder between the old items must be deleted and two new ones inserted after the piping item has been inserted. It is generally very difficult to modify pipes once they have been created (i.e. drag etc.).

Gaskets are not modelled at all they come as part of the flanged item. Only one gasket thickness per specification is allowed.

There is no on-line data consistency checking. (Batch queue only on a model file) because the check program draws circles around the errors and must therefore open the Microstation drawing (model file) open with write access.

PDMS allows the user to have on-demand consistency checking as well as a complete consistency check of the project with a report which can be used as a standard deliverable.

In PDS you can not declare a clearance from another item when positioning a component. You can only snap on the graphic representation of an element.

PDMS is very flexible in the way it allows you to drag and modify piping sections. There are also some useful options for positioning piping items to ‘Top Of Steel’ or ‘Bottom Of Pipe’.

3D Clash detection

PDMS maintains a spatial volume map of the design while users are working. All disciplines are available for checking at any time and automatic sketches of a clash can be output. PDMS can also recognise the difference between ‘touches’ and normal clashes.
There are three methods of checking available :
1. Users can do on-demand checking at any time.
2. Automatic clash checking can be switched on in confined spaces.
3. A global batch procedure can be used for formal project clash checking.



PDS is not based on solid geometry. The system must define envelope files and is a batch only function because the clash check program draws circles around the clashes and must therefore open the Micro station drawing (model file) with write access. Also PDS cannot have negative volumes which mean that many ghost clashes are produced.

PDS has no on-line clash detection facility.

PDS is not able handle touches which makes reports very large.

PDS report cannot give exact 3D location of the clash.

Due to the organisation of the PDS data it is possible to have clashes between disciplines which are not detected by the system.

Drawing and Isometric Production

PDMS can automatically produce piping isometrics using the Isodraft

Source: yahoo answers



you may also like: MOST READ

No comments: