Seven Steps to Specifications

A major task of FEED is to put together specifications for various equipment, systems and facilities that go into the plant. Here are seven steps to construct a meaningful specification:

•Duty
•Design Conditions
•Codes and Standards
•Scope
•Inspection, Testing & Documentation
•Guarantees
•Spares

FEED

Until very recently, the life cycle of a CPI project followed the familiar well trodden path of Technology Selection, Basic Engineering and Detailed Engineering followed by the process of implementation and start-up. This comfortable situation has been rudely disrupted of late by a new activity called Front End Engineering and Design, known more popularly by the acronym FEED. In the earlier days the inadequacies of Basic Engineering, and there were a surfeit of them, were taken care of by the Detailed Engineering contractor. These inadequacies were primarily because the project owner (the client) would rather pay the local DEC for the touching up than pay through the nose to get a ‘perfect’ Basic Engineering Package (BEP) from overseas. But with projects increasingly being bid on a Lump Sum Turn Key (LSTK) basis, the BEP cannot be incomplete, inconsistent or inadequate. The main purpose of FEED is thus to flesh out the BEP into a level so that the LSTK bids can be obtained in the shortest possible time.

More on Hazop…..

For Hazop to be effective and interesting it is necessary to deconstruct the P&I D’s carefully into the right number of NODES. Nodes have to be meaningfully and logically selected. Making the node too big in order to save time will be counterproductive as analysis will be frustrating. Too many nodes will end up trivializing the Hazop. It is useful to have one parameter, say flow, or temperature, or pressure unchanged in the Node.

Hazop software takes out the drudgery from recording the observations in long hand and nothing more. The constant ‘cut and paste’ may take out the drudgery but also dulls the mind. There is a danger of repetitive and monotonous thinking.

Thoughts on HAZOP

I am posting after a long hiatus (blogging is for me the most difficult task to get myself motivated). After a long time I had an opportunity to be the Chairman of a Hazop Study and the excitement and satisfaction of that experience is substantially responsible for reviving this blog, and for which I have selected some random thoughts on Hazop.

Hazop Study, in addition to a review of the HAZARD and OPERABILITY of the process also serves two other important purposes:
•It offers an excellent learning session in Process Design and Engineering for rookie engineers of the EPC Company.
•It provides an excellent refresher course for the client’s operating personnel.
Both these are possible if the client participates in the process with great gusto, which unfortunately is not always the case. Many clients are content with the EPC Company carrying out the review on their own and are only interested in the getting the report that has to be furnished to bodies like the Factory Inspectorate for obtaining the required statutory approval. In this way an important learning opportunity is squandered away.

Hazop is a clinical and structured investigation of the P& I Diagram. This is done by examining each line and equipment or a cluster of lines and associated equipment, termed as ‘NODE’ (I prefer the nodal approach as it is far more elegant than the line approach) for deviation from the intent. This deviation is discovered by using a set of ‘GUIDE WORDS’ originally proposed by ICI and later augmented by others. Against each deviation, the CAUSE, CONSEQUENCE and SAFEGUARDS have to be recorded. It looks simple, but quite often engineers tend to confuse these three apparently simple concepts and this is where the stewardship of the Hazop Chairman is needed.

Another common pitfall is that many engineers discover the ‘safeguard’ first and jump to the conclusion that the ‘cause’ and the ‘consequence’ are unlikely. Here again the Chairman has to intervene and force the team to think through the process sequentially and hierarchically. The ‘cause’ for the deviation is not always easily apparent. If after some brainstorming the team fails to discover the ‘cause’ it is prudent to drop the deviation from further analysis. ‘Consequence’ is either an undesirable event or an excursion of the process parameters. ‘Safeguards’ can be of two kinds:
•a measure which prevents the ‘cause’ event
•a measure which detects or mitigates the consequence

The following would qualify as ‘safeguards’
•Alarms
•Interlocks and plant shut-downs
•Standby equipment
•Safety valves
•Appropriate choice of design pressure, temperature and material of construction


Some gray areas always crop up during every Hazop. These pertain to the maintainability, availability and reliability of the hardware, and are a separate subject in itself.