Beginning Project Engineering: Design Principles

Design Principles (DP) are not Basis of Design (wrongly defined as collection of specifications, regulations, standards, and even the work scopes to be delivered at the FEED stage). Unlike the latter, they are universal and valid for all the projects and companies.

As DP work at the level of ideation, conventional engineering never considered them an asset. Digitization we are witnessing keeps on destroying conventional wisdom in many ways. One is turning relegated principles into smart algorithms driving automation and artificial intelligence.

It turns out that DP may be a solid and single foundation for software development, managing engineering of complex systems like desalination projects.

They follow the 90/10 rule (others – 100/0). 90% of the project engineering is done by copy-and-scale of the parts from the past projects. 10% is new design from prototype or from scratch.

DP govern both approaches – copy-and-scale and from-scratch. Specifically, DP focus on how from-scratch may be turned into copy-and-paste.

To explain the last point, let's turn to the Sorek desalination plant (Israel, 2013). It uses 16" membrane vessels installed vertically. Surprisingly this unique and promising design had never been replicated by the contractor in the projects following the Sorek one. Obviously, marketing failure is rooted into flawed DP.

Another task of DP is whether to stay with copy-and-paste or move to from-scratch. Such moves are always associated with long-term strategy, they boost the company engineering culture and services versatility.

An example is Reliance 164 MLD SWRO plant pretreatment system (India, 2016). The engineering services provider – expert in gravity filters – did not find another solution as to offer the tandem of what it used many times and the UF technology (never officially referenced by that time). 

This overkill design reminds me of Albert Einstein saying "We cannot solve our problems with the same thinking we used when we created them". Filtration plus better (but unknown) filtration is not a solution; it is a manifestation of weak DP.  

Importance of DP rises on the wave of Digital Water as it changed our perspective from making better products to creating better customer experience. Strong DP are a condition for experience diversification.

Modularization

To make engineering system eligible for copy-and-scale technique, it shall be designed with modularization in mind.

This basic principle states that to achieve reusability, systems should be built from cohesive, loosely coupled modules.

Each module should have a well-defined global function or purpose. The last is described by a verb, like to pump, to filter, to chlorinate, etc.

In other words, modularization requires changing engineer's perspective from HOW it works to WHY it is used. 

And the first step to modularization is moving from Process Flow Diagram (HOW) to Plant Modularization Diagram (WHY). This presentation of the plant functional allocation lists all the modules (with functions) and their interdependencies.

Unlike loosely defined PFD, PMD adds rigid structure to the plant – the basis for the project scope definition.

The Plant Modularization Diagram (PMD) excerpt is shown below. It is from crenger.com S1800 project available online. PMD may be easily auto-generated from P&ID. The next step is to teach the software analyze and rate the plant design. These ideas drive the Crenger platform development.

The less interdependencies between modules, the more mature the plant design is, and more reusable the components are. 

Is reusability saleable and shall be addressed by the marketing? Definitely. Reusability is an amplifier of the product/service market value.

Modularization leads to much better functional reliability and predictability of the project costs and the time schedule, faster testing and commissioning, and the plant scale-up. It is an indication of the product/service maturity.  

To benefit from modularization (and the design reuse), the module function shall be complete, unambiguous, precise, and easily understood.

Design reuse turns engineering services from batch business (of the project execution) to perpetual one of designing modules.

Turning module design into a token of engineering services in the form of digital twin will disrupt the way the project engineering is done today – "reinventing the wheel" again and again.  

Recurring Items Pattern (RIP)

Defining the module functionality by a verb is not enough. Primary quantitative characteristics include reliability and production flexibility. Enhanced functionality is easily obtained in a module represented as a number of RIP groups connected in parallel. Each one is the same combination of the P&ID items.  

For example, to pump seawater with dependability of 100% and flowrate ranging from 20% to 100% at least 3 intake pumps are needed as usually for the turbine type pumps the allowable minimum flow rate is around 40%.

As follows from the example RIP is a building block of the module with predictable reliability and the production rate.  

Introduced quantitative characteristics make the modules comparable and pose the obvious question - which module controls the plant? The one with the lowest reliability and production flexibility. And it does not matter how good the other modules are.

Recurring Design Pattern (RDP)

Similar to RIP, RDP is part of the module. Unlike the former, RDP does not have a clearly defined function. it is a stable combination of P&ID items (having well defined functions) reused in similar process implementations.

For example, the discharge piping of the intake pump driven by variable speed drive will definitely contain the flow meter, definitely of the electromagnetic type. (See figure above) The same discharge has to contain the air release valve, and so on.

RDPs are described by the collection of so-called good engineering practice rules and industry practices. 

Crenger.com contains a rich collection of RDP blocks.

Module States

If one of the modules performs unsatisfactorily, can we say that the whole plant performs off-spec?

To answer this tricky question - FAQ of the plant warranty - we need to define all the "shades" of the plant performance "health". To do this we have to define the allowable module states.

Crenger.com introduces the following basic states.

Fault, Not Ready, Ready, Running, Not Healthy

The Running, Ready, and Not Ready states are reversible: transitions between them are controllable. The Fault state is abnormal and risk associated one. Any transition to it is unidirectional and irreversible.

Depending on the module purpose, even if it is in the Fault state, the Plant may be considered Healthy. Not Healthy is a good reason for call to the plant contractor.

States Propagation

The majority of desalination plants have a big design flaw - they do not fail safe. If something goes awry, the associated piece of equipment is shut down without regard to its neighbors. Unfortunately the existing control engineering standards disregard this problem. Reason? No means for problem description. Time to recall again Einstein's words.

Modularization approach raises a number of questions. What happens if one of the modules gets Fault status? How far this status will propagate and in which direction? What means do we have to control the propagation?

The situation will look less complicated if we introduce the following constraint.  

If the Running state propagates downstream, then the Fault state shall only propagate upstream. In other words, Fault shall mirror Running.  

This constraint is a key to fail-safe plant design. Figure below shows a train of the modules additionally grouped in operation modules (OM). Typical desalination plant includes the following OMs connected in train – intake station, pretreatment, SWRO, BWRO, posttreatment, and auxiliary systems.

In good design any chain of OMs beginning from the first (intake station) may operate continuously without interaction with downstream OMs. (Otherwise how can we perform commissioning of modules?)

This feature is remarkable as it blocks the Fault propagation upstream. Figure above explains how it happens. Malfunctioning groups are not allowed generate Fault directly. They initiate fault propagation from the last OM. At the same time all the predecessors coast to minimal controllable load. 

How do these Design Principles accelerate Digitization and Industry 4.0? I'll try to answer this question in my next post.