By Sean Moran, C.Eng, P.Eng, Expertise Limited
Chemical Engineers are often known as process engineers in professional life, but we do not design processes - we design process plants. Engineers design physical artefacts, and a process is not a physical object. Process plants are – they are made of concrete and steel, wires and pipes, tanks and pumps. Processes happen in them.
The process designer specifies the physical subcomponents., and how they are to be connected and controlled in order to safely, reliably and economically carry out the process. The process is an emergent property of the specified collection and interconnection of parts.
The process of selecting and specifying the parts and their interconnections involves a great deal of professional judgement, as well as the judicious application of engineering science and mathematics.
The documentation of these choices is done largely by means of drawings. Drawings allow the communication with other engineering disciplines which is necessary to optimise the plant design. Drawings are the things which the people who will build the physical plant need to do their jobs.
This is process plant design, a rather messy, intuitive, collaborative, multi-disciplinary, multifactorial business. It involves negotiation and discussion with electrical, software and civil engineers, equipment suppliers, those who will procure, commission and operate the plant.
The precise process conditions to be used are actually not that important a part of the whole activity, and if we are honest with ourselves, we cannot as designers predict the conditions within the plant as constructed to a high degree of precision. A good process plant designer makes sure that the plant design envelope encompasses the range of conditions that the plant is likely to see, and that it is robust enough to maintain adequate performance across that envelope.
There has however grown up in academia a school of “process design” whose adherents have never designed a process plant - instead they “design” processes. Modelling and simulation programmes attempt to stand in for the process plant whose actual construction tells you whether you are a good designer or a bad one. “Process Design” as practiced by these people is a form of mathematics. The techniques they practice are never tested against reality by building a plant based on them. The textbooks they write are like descriptions of a rainbow by a blind man.
The guidelines published by the IChemE’s CAPE working group are seemingly unknown to those practicing this approach. Our guidelines say that if a computer is used by a chemical engineer in the course of their professional work, it is the responsibility of the practitioner to verify the validity of the inputs, to validate the applicability of the program used for the application to which it is put, and to understand all defaults and assumptions built into that programme, It is the responsibility of the practitioner to distrust the output of the program, and to check the outputs thoroughly for sensibleness.
The idea that a computer program’s output might be a form of proof of a design is radically at odds with these guidelines, which understood the many ways in which modelling and simulation programmes and even the humble spreadsheet cab be abused. There has recently been a short but conclusive debate in the TCE about the results of the” Towards Zero Prototyping” initiative, which attempts to replace a real trial with a virtual one. Software company reps may claim that great progress is being made in this direction, but professional engineers are not convinced.
We know who writes these programmes, and the limitations of the platforms on which they run, and we see them being misused by the young engineers universities are turning out who do not understand these things.
Modelling and simulation programmes are generally written by software engineers, aided by miscellaneous physical science graduates, and graduate chemical engineers. These young engineers are products of an engineering science education, with little or no input from anyone who ever actually designed a process plant. They have had no opportunity to develop professional judgement.
Unfortunately if you are writing a programme which models or simulates a process plant, you have to build in many assumptions and take many shortcuts in order to get it to work. Such work is itself a kind of engineering, so you can no more write such a programme using only maths than you can design a plant using only maths. You have to use heuristics to plug the gaps and uncertainties in your knowledge.
Those writing these programmes were largely taught by people with no process plant engineering experience, and now work with people with no process plant engineering experience. They have to set certain variables to default values to make the programme easy to get going. They have to simplify mathematical models of physical sciences to work reasonably quickly on readily available computers by making assumptions which become implicit features of the programme.
They usually offer users standard databases of physical properties, whose data’s original sources would have attached margins of error to the measured properties. They may well arrange for the programme to helpfully generate intermediate values by interpolation, and (worse yet) out of range values by extrapolation.
Most unhelpfully of all, many get around the difficulty of only including a limited range of unit operations by allowing users to set up imaginary unit operations called something like “separators” to stand in their stead. These allow the programme operator to set up a unit operation which by unexplained means divides an incoming stream according to the programme operator’s wishes.
There are in fact normally three ways to address the problem of a missing unit operation. One can substitute it on the programme’s flowsheet with something the operator thinks is pretty similar, (as I have seen students substitute absorption columns for cooling towers in hysys), use a “separator”, or (much more difficult) write your own reasonably accurate module of the missing unit op. Human nature being what it is, I don’t see too much of this last option.
These programmes are useful tools, but the CAPE working group’s advice to treat their outputs as guilty until proven innocent has been reversed. Their outputs are now considered by many equivalent proof of a design to actually building the plant.
So a circular process has been created which never actually checks whether its models really work. University departments teach engineering science, and give students the impression that process design can be done using a simulation programme based in that science.
I’m sure there are many reading this who are under the impression that they have “designed” plants using these programmes, had them built, and they work. My background is in process contracting, and before the CDM regulations came in, everyone considered themselves to have designed the plant. The client and/or their consultants would carry out conceptual design studies, and an invitation to tended based on their outputs would be produced. They often told themselves that the contractors were really only collecting together the equipment which their work had basically specified, and deciding how to bolt it together.
Process contractors redesign plants from the ground up, as they were the ones offering the process guarantee, and this offered the greatest opportunity to profit through their engineering skills. They saw that it would upset the clients and contractors upon whom they rely for work not to contradict the impression that clients are designers until the CDM regulations came along, with their legal responsibilities for whoever the designer might be.
Now we all know that it is the contractors who are the designers of the plant which is actually built, though they still do not hammer home this point, or point out that most conceptual design work in client organisations and consultancies is a waste of time and money.
“Design” by modelling is most popular in such operating companies and consultancies, and they may be under the impression that their conceptual design is what has been built on the basis of a polite fiction.
To return to the issue of “process design”, these programmes allow a “process” to be “designed” and supposedly optimised in a model space which has no limitations in physical layout, no distinctions between the available types of equipment, no consideration of commercially available model sizes of equipment, no real consideration of cost impacts, and little consideration of many safety, environmental and QA issues. Any “optimisation” which does not rigorously consider cost, safety and robustness as the paramount variables is setting in stone a bad design basis.
Only the most rigorous programme operators will ascertain whether the thermodynamic and physical data is valid over the ranges of physical conditions used, and how large the uncertainty associated with the product of all of the uncertainties associated with the use of that data is. Few indeed will talk directly to programme vendors and writers to understand all of the assumptions built into the programme.
The programmes output is usually presented in a spuriously precise way. With a rigorous understanding of compounded potential error and a sensitivity analysis, there may well only be two or three significant figures at best.
There is nothing wrong with data with two or three significant figures, unless one starts to believe that the model is the thing itself, and that professional judgment is no longer called for. As the CAPE guidelines say, outputs need to look sensible-modelling programmes can produce garbage outputs even if properly operated.
This inward-looking, self- referencing school of designing plants in a virtual world has become prevalent worldwide in research-led university departments. Research in this area is very easy to get funding for, as it only requires a computer with modelling software, a desk and a researcher- all pretty cheap nowadays. These researchers are encouraging university departments to give up on teaching plant layout, drawing, and any residual practical engineering or even hands-on laboratory skills, and to replace them with their solipsistic approach. They say that it is the job of industry to teach graduate engineers to actually engineer, and universities should teach only science, mathematics, and the research interests of lecturers, (most of who do not have engineering degrees).
This is would be both a great deal cheaper for universities, and closer to the comfort zone of many of their staff, so it is a siren song. Only the IChemE’s accreditation guidelines stop many more universities from listening to it. I would urge professional engineers to help IChemE in its efforts to reforge the link between practice and academia which has in many places been broken.
This is no trivial matter. Many now believe that this fundamentally flawed approach can produce plant designs which require no additional safety factors. This looks to me exactly like the process of erosion of safety margins leading to many engineering disasters which Henry Petroski discusses in many of his books. A simple pressure vessel is usually designed with a safety factor of 4 – designers of far more complex process plants need the humility to acknowledge our persistent inability to control and predict both nature and art.
We do not yet understand or control the physical world to the point where first principles designs are safe, robust or economical. I would invite anyone who disagrees to fly in an aircraft with the safety factor of 1 which some of our plants are now approaching.