Desalination Megaprojects: Basis of Design Automation

All desalination megaprojects have the same starting point - the process flow diagram (PFD). It outlines the plant design - the main process definitions and sequencing necessary to provide the required product quality and quantity. The process definition normally contains design capacity, standby capacity, and load duration. Annotated mass balances for a set of operation modes always include chemical dosing rates and pH values along the process path.

The biggest problem of conventional PFD described above is that it represents only 10% of information associated with its development. The logic of decision-making and design optimization are hidden from a client. Paradoxically, all this dirty work is what the client needs to select the preferred bidders.

To mitigate the above-mentioned problem In the pharma, oil, and gas industries PFD is paired with the Basis of Design (BoD) document. In the water industry practicing once-through bidding, BoD is not well acclaimed. Desalination megaprojects contracted as PPP (public-private partnership) neither mention BoD.

If BoD seems of marginal value in the water industry, why raise this topic? The obscurity of the BoD definition and application is not a reason to discard it in moving to digital engineering. On the contrary, it is a sign that some links may be missing.

The conventional definition of BoD neither gives a clue to the link nature nor considers BoD as the PFD extension. It is viewed as project-agnostic and intended to list the criteria and assumptions on which design calculations and decisions are based.

Worse, BoD is often a synonym of the owner's instructions to the engineering contractor about what the owner wants engineered, and how the owner wants the process engineering to be done. Logically, the BoD addressee should be the project owner, not the contractor.

In the digital world, BoD is associated with a point where Systems Thinking (ST) stops and Engineering Thinking (ET) begins. It is a transition from deep abstractions of the design phase (DP) to shallow ones governing the engineering phase (EP) of the project.

In software development, one should be aware of four far-fetching implications of the DP-EP transition governing direction and the depth of the project engineering automation.

1. As the deep abstractions generalize the shallow ones, the DP automation should be started after (!) the EP automation has been completed.
2. Unlike the latter thriving on the Human-Machine Interaction (HMI), the former goes in the opposite direction: the less HMI, the better it is.
3. DP and EP pursue different goals: DP shapes the plant as a collection of interacting systems while EP is confined to a system scope. DP produces reference bounds for EP. Disregarding this fundamental difference is a reason why conventional engineering wrongly calls DP's results a "preliminary design".
4. In the software parlance, DP generates the "data envelope" and "business rules" for EP to follow.

For a company that has succeeded in DP automation, BoD is a unique opportunity to demonstrate this success to clients. Points may range from design optimization to correction of mistakes and ambiguities of the project tender (which are quite frequent) to sharing know-how (as part of the branding strategy) as the BoD format is not standardized.

An example of design optimization is a direct air floatation (DAF) system. Its specific hydraulic load - the key design criterion - ranges between 5 and 50 m/h. Meager design experience and complete risk aversion coincide with the lowest value. Moving to higher ones requires not only deeper experience but a different perspective of systems thinking.

The rising complexity of infrastructure megaprojects with high costs and long cycles of prequalification and bidding (US$1-5 million, 1-2 years) necessitates moving to two-stage bidding. The first stage should screen out the preferred bidders with cutting-edge BoDs. In the case of the automated DP, the time needed for the creation of such BoDs is less than 30 minutes.

The top of the DP/BOD automation iceberg implemented by crenger.com is represented by three user interfaces. The first one collects the owner's instructions (!) on various aspects of the plant design. Here the owner "assembles" the plant from the standard processes and adds a set of custom requirements. Next, the designer updates the auto-generated mass-flow balances for several operation modes of the owner's basic PFD. Finally, the designer runs the BoD editor overlaying PFD on the auto-generated plant layout. When the element of the layout is clicked the third layer - the main equipment selector/designer - is activated. The BoD document sample may be found on the crenger.com site.

Reprinted from crenger.com