PDMS / PDS Technical Comparison

Management Overview
This document is technical comparison of Cadcentres PDMS product against
Intergraphs 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 applicationware (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 items 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 Microstation drawing (model file) with write access. Also PDS cannot
have negative volumes which means 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(s):
Confidential