Global Business Environment
for desalination and water treatment projects
Introduction into PFD and P&ID
GBE is inseparably tied to a number of diagrams: the plant general layout (GL),
process flow diagram (PFD) and process and instrument drawing (P&ID),
sometimes called piping and instrumentation drawing.
This collection of diagrams is collectively called P&ID.
Below are the sample diagrams used in a SWRO Demo Project.
PFD may be defined as a deliverable set of documents defining the constituent
processes functionality and process sequencing (flow of processes) necessary
to guarantee the required product quality. PFD is a synopsis of the project
and declaration of the design targets set. PFD may be interpreted as a
set of guaranteed figures for the whole plant and its main and auxiliary
systems.
The constituent process description shall include required production
rates, product quality, energy efficiency, process dependability, process
flexibility and maintainability, and potential risks and environment impact.
Usually the PFD set of documents includes a graph of processes and the
process annotations. For desalination plants featuring high energy consumption
and handling continuous streams of fluid, PFD is accompanied by the Mass
and Energy Balance tables as part of the stream conditions definition,
entering and exiting the process.
What other purposes does PFD serve?
For P&ID drafting any drawing program may be used: MS Visio, Adobe
Illustrator, AutoCad or even MS PowerPoint. Visio is inexpensive and produces
good-quality graphics in all known image formats: gif, tiff, jpg, png.
Illustrator, renowned for the best quality graphics, is the favorite. The
last version of AutoCad is expensive and obviously an overkill. Besides
it doesn't produce good-quality images needed for internet-linked activities.
(P&ID images generated with these programs are the input to GBE.)
Sometimes engineers especially those not versed in the data management
try to use specialized packages linking AutoCad to the raw database like
MS Access or Oracle. On the first glance those graphics driven programs
seem appealing: symbol and some textual data become bi-directionally linked.
But the end is the same - customization failure. The main reason is that
the P&ID graphic symbols are an abstraction - like a top of an iceberg
- hiding the wealth of information beneath the water level. This information
hierarchy and laws are unknown to the graphics driven programs. Their
customization in practice turns into hard work from scratch. Trying to
plug these programs into already existing
ERP system may be very expensive enterprise doomed to failure as the programs
in question are not built for networking.
Another point to be reckoned with is poor maintenance and service of these
programs as the dedicated staff usually does not have any knowledge in
the process engineering. Serious problem associated with the above programs
is the lack of qualified users - the engineers avoid practicing in drafting
by all means, and the draftsmen are not qualified enough to manage the
drawings database. As a consequence many engineering companies in water
industry have no internal graphics standards. Not seldom "improved" PFDs
are used instead of P&IDs for small-capacity-unit projects. As a rule
such P&IDs have no one-to-one correlation between the diagram symbol
and the database entry. It is said they don't fit into WISWIG - "What
I See What I Get" - mainstream concept of the programs in question.
And the legacy P&ID problem is still left unsolved.
There are numerous graphics-driven programs for P&ID development available
on the market
In the lack of means for the P&ID data management, P&ID itself
turns into the project data main repository. It becomes overloaded with
various kinds of seemingly unrelated information pieces - the pump performance
data, piping and fitting sizes, ground and water levels, valve design
details (rotary valve of ball type or butterfly one?), number of solenoids
in the pneumatically actuated valves, and even the assembly drawings of
the injection nozzles for chemical solution. Attempts are being made to
standardize this information chaos - more details may be found in the
presentation by Jeff Ratush.
The solution to this problem is straightforward once one accepts the fact
that P&ID is the worst kind of database ever known as its data cannot
be read by computer.
P&ID development criteria adopted in GBE
Task
Task weight, %
Task criterion
Learning process basics
30
More general and simpler symbols are better
Equipment procurement and mechanical design
30
P&ID is a browser of database
Control design
40
Affinity to control logic concepts and entities
GBE uses multilayered P&ID approach - the upper (graphical) layer contains
only conceptual and general information about the process and its means.
The P&ID symbols provide effective shortcuts to other layers of information
- item geometry, construction and materials, control and electrical data,
and the product information. The upper layer is a "common denominator"
readily understandable by all personnel involved in the project - process
engineers, electrical and control engineers, project managers, mechanical
engineers, unit operators, technicians and drafters. It can be said that
P&ID is a roadmap of the project.
To most of the P&ID experts the task to teach everybody to read P&ID (upper layer)
may seem absurd bearing in mind recent heavy updates of the industry standards introducing
more complexity and new abstractions (in a single layer) and a work grandiosity - IEC guys
invested more than 7 million US$ and 12 years of hard work into ISO 14617 “Graphical symbols for diagrams”
(ISO Bulletin March 2003).
Use-case analysis shows that the personnel with basic technical backgrounds easily handle
the task of deciphering P&ID compiled of 66 generic symbols carefully sorted out by Piman and
denoting already known common-knowledge abstractions. For comparison, similar complexity abstractions -
road signs – include 47 warning signs, 68 direction signs, 61 information signs and 20 road markings.