Everybody talks about design efficiency until it comes to procurement and construction.
The construction phase is less diverse than the design or pre-construction phase. What I mean by that is there are more ways of designing wire gauge, equipment or reinforced-concrete columns than the ways of their procurement and installation. So procurement and construction are the main constraints for the design phase.
Moreover, a construction site is where efficient design can become a hell for the procurement/construction crews. You can imagine the most efficient reinforced concrete structural frame for the irregular shape open space office building with eight types of internal columns, twelve types of external ones and a couple of different moment frame column types. The guys responsible for installing formwork wouldn't thank you for this efficiency, and even for the project owner, the money saved on reinforcement and concrete will be lost during construction.
Being more specific about where is construction limits the design
The short answer is everywhere and from the very beginning. For example, you cannot design PV Farm Layout without having equipment in mind available to buy in the market.
Let's go through a specific example.
Turn on our imagination and isolate a small ~18 acres parcel of land from a much bigger PV farm. As shown below, we have an East-West road, a 3-height trackers configuration - each tracker has 3 strings with 33 solar panels each.
There are many different ways to connect solar panels to the inverter.
We will use a <extender - trunk bus - DC feeder> low voltage wiring pattern (see the conceptual diagram below).
The pattern defines the path and sequence of how equipment is connected to each other.
Applying this pattern to our layout will allow us to see all the wiring from modules to the inverter SKID.
So we have a wiring path, the current after each step in the scheme, maximum allowable conductor temperature and maximum voltage drop we can afford. Those are our constraints in seeking the most efficient wiring gauge size. The central concept regarding the most efficient wiring is to choose a wiring gauge size and material that provides needed resistivity under the required temperature and below the maximum voltage drop. To make the truth-seeking even more fun, we can add the cost of the cable. But the cost of the cable has a linear connection with the volume of the cable and material type coefficient (assumption) so that we can minimise the volume of the conductor and consider this criterion as an efficient design criterion.
We are killing it and providing the most efficient wiring gauge design. 💣
As a result, we got 4 different types of trunk busses, which happened because the positions of DC Disconnects were chosen to minimise DC Feeder length. Therefore we have different wiring lengths for various circuits, hence different gauge sizes.
But the procurement engineer and site crew don't accept such excellence because only for this isolated ~18 acres parcel of land we do have 17 different DC Disconnect circuits. The whole site is about 1800 acres and around 1700 other DC Disconnect circuits, and even if we stick to four different types of Trunk Bus, the team will struggle to figure out which one should go where. So our efficient design creates problems for procurement, staging and construction.
Through communication with construction teams pre-construction team takes procurement, logistics, staging and operations contexts into account and makes a good enough design, saving money for the owner. Happy end! 🌞
But this blog is not about that, so let's keep going.
As we see above, the procurement and construction coarse the design and it is totally fine
Moreover, the design phase should be done with construction in mind. The best mental model that describes it is inversion. Thinking backwards about how we can build PV Farm or any other systems/buildings, we can do a better design (better from a final purpose standpoint).
How should this coarsening be handled when building configurators for contractors?
The building configurator is an automated pre-configured or pre-engineered building concept system.
And the question here is shall we embed those operational heuristics when automating building concepts? And if so, how?
I think we considered enough pieces of evidence above that design optimisation itself doesn't make much sense when you want to build something. So those so-called operational heuristics should be taken into account.
The remaining question is how we should do that?
In my experience, almost every object generation/configuration problem is an optimisation problem. Thus vanilla solver scheme can be described in a pretty simple way - constraints, criteria and their weights as input and something as an output. A solver can be a part of the pipeline so that the output can be an input for the next solver or further postprocessing.
There are a few possible places where we can put an operational heuristics (from a user controls standpoint):
As Private Constraints We can incorporate those as 'easements' inside initial algorithms. So-called private constraints are not available for the user to control.
As Public Constraints Users can control those constraints but cannot launch an algorithm unconstrained.
As Postprocessing Solver The initial solver launch is unconstrained by operational heuristics (efficient design solver), and all operational constraints are incorporated in the separate postprocessing solver. It is a kind of two-factor system.
The first approach is the easiest to build because we can use those hidden constraints as algorithm easements. Let's assume that we have an algorithm that calculates wiring, as in the example above. And we know that contractors would never use more than one type of DC Feeder cable. DC Feeder is a conductor that connects DC combiner boxes or disconnects with inverters. Suppose we use the same type of combiner box or disconnect for the whole site with global settings around temperature and maximum voltage drop. In that case, we know that the only variable for wiring gauge calculations is the length. So instead of calculating DC Feeders 1700 times (as in the example above), we can find the most extended cable, calculate the wiring gauge and apply this cable for the whole site (fake optimisation with no way back).
But it would be an overconstrained solution for those who want to test different considerations like having two-three types of DC Feeders.
We can solve this problem using the "As Public Constraints" heuristics placement. In that case, users would be able to control this heuristic and play around with some tradeoffs like the complexity of installing different types of conductors vs the cost of materials. The only limitation such an approach would have is the impossibility of an unconstrained launch.
Thus from a solution perspective, the third approach, "As Postprocessing Solver", is the best because it would give us a fantastic opportunity to compare the cost of the most efficient design to build vs the most efficient construction to design.
We should always keep the construction in mind when designing, as we figured out above. Still, in some cases, the most efficient design can save us more money than the most efficient construction, so it is essential to have this opportunity to compare. The third approach is the most labour-intensive and time-consuming to think up and build, but it is the most flexible and insightful to use.
In addition, from a solution architecture (not building architecture) standpoint, the "As Postprocessing Solver" approach is the best one because it gives us a modular and scalable system of solvers.
The most efficient design to build vs the most efficient construction to design
The main difference between configurators for pre-construction and construction is in context. The last is more worried about the places that can cut their profit (skin in the game business as usual), namely, logistics, staging, sequencing, labour operations, and construction.
But generally, it is always a tradeoff between the most efficient design to build vs the most efficient construction to design. Therefore, the tradeoff often lands up into material cost vs labour cost vs plant cost. Thus for similar buildings/systems, completely different decisions can be made in countries with cheap labour and expensive labour.
And this is one additional reason to keep operational heuristics as separate postprocessing solver constraints if we want to build a scalable building configurator.