Process Control System (PCS) Design
It is worthwhile considering the extensive use of a database system in the production of the Process Control System (PCS) Design documents which are to be used as input documentation by the system supplier.
The generation of ‘base graphics’ MUST be configured by the operating company since a supplier just does not have the experience to produce graphics which accurately reflect the process. It is not simply a job of ‘copying’ the P&IDs. The most effective way of configuring these base graphics which the supplier enhances is to use the supplier configuration package, thus having the ability to transfer the data to the supplier database easily.
It is also a great idea to use a Database for creation of the Instrument Index , Cable data Sheets, I/O schedules, Message Lists and Motor Schedules as data can then be effectively transferred from one database to another. This does have the added advantage in that errors are minimised once one database has been checked. Mind you if adequate checking does not occur then the problem will be multiplied.
The following input documents should be produced for issue to the Process Control System (PCS) supplier. Some operators consider that it is more effective for the PCS suppliers to create some of these documents but that is just not so in that they just CANNOT have adequate experience to provide a comprehensive enough package.
(1) I/O SCHEDULES
These are the base documents around which configuration revolves, information contained within it should include tag number, whether it is an Intrinsically safe or Non I.S. loop, digital or analogue, range, units, critical or non critical loop, report input and alarming priority.
(2) FUNCTIONAL LOGIC DIAGRAMS
T hese are the base documents which the supplier uses for motor and sequence control. They are usually drawn utilising logic blocks around the logic symbols which are identified in AS 1102.9 - ‘Graphical Symbols for Electrotechnology - Part 9 Binary Logic Elements’.
(3) MESSAGE LISTS
These lists are the base document which are used for the generation of reports, alarm and special messages. They are usually configured using a database format which the supplier can easily transfer to his own database.
(4) BASIC GRAPHICS
The rudimentary graphics which are initially passed to the operating company OPERATIONS GROUP for comment and then used by the supplier as the base graphic background which the supplier then enhances.
(5) CABLE DATA SHEETS
These sheets are used rather like termination diagrams where normal termination diagrams do not exist.
(6) MOTOR SCHEDULE
This document details the requirements needed by the energy management system ie priority of tripping.
(7) TERMINATION DRAWINGS
Details of all incoming/outgoing terminations and cables.
(8) FUNCTIONAL DESIGN SPECIFICATION (FDS)
This document specifies the functional and technical requirements of the system. It should be comprehensive and miss nothing. ‘Slimline’ specifications DO NOT work and leave the customer wide open for variations.
THE CONTROL AND INSTRUMENTATION 'TAIL END CHARLIE SYNDROME’
It has always been the case that the Controls/ Instrumentation design could not be finalised until the piping design has been completed because the instrument locations are unable to be adequately determined. This of course is true if total accuracy is required, however, if you have a schedule problem there is a method of achieving 90% accuracy at a very early stage, picking up the remaining 10 % at a later time.
This method utilises the base vessel layout and allocates instrument positions on a ‘best guess’ basis (usually they are very close to the final position) and ‘driving’ package vendor terminations at edge of skid. The suppliers we have found are not adverse to this approach as it does do a fair bit of design for them.
THE ‘LOST’ INTERNAL SYSTEM INSTRUMENT TAGS
It is always a problem as to just where you pick up internal system tags and tags which do not appear on the P&IDs. A convenient method of picking up these tags is to use a document called a Instrument Line Diagram. The ILD is essentially a point list and can be in diagrammatic or data format.
This document however must be treated with great care in that it can become a monster if you are not careful. Keep it as simple as possible, utilise it by all means as a tool for creating ‘temporary P&IDs’ when package P&IDs are not available but ensure that the tagging system used does not cause problems later.