Converting traditional floor plans into Modular

Arguably one of the most conservative markets globally is the construction market, and in particular where we see pre-manufacturing. To make this topic even more specific - how the industry manages the implementation of volumetric modules into the pre-construction phase; what problems we have there, and possible solutions.
IndexTvsM

Current process and roles

Let’s start with process cognition and a description of roles. The construction process is pretty complicated. Under the RIBA Plan of work 2020, it has 8 different stages, which are designed to work together to inform the briefing, design, construction, handover and use of a building:

Converting traditional floor plans into Modular 1-1

Aside from the  RIBA stages, there are planning / contract stages, different procurement routes, etc. Like Lebowski said, "This is A Very Complicated Case, Maude. You Know, A Lotta Ins, Lotta Outs, Lotta What-Have-Yous."

But we won’t let this complexity put us off!  🧤 Let's consider a pretty typical case:

  • Client/developer
  • Architect
  • Contractor
  • Manufacturer

It would be difficult to explain the relations between these in under 100 pages, but here’s an attempt at a simple scheme:

Current scheme

  1. Client/Developer sends brief requirements to the architect
  2. Architect produces floor plans without thinking about pre-manufactured volumetric modules
  3. The contractor gets drawings, sends RFP (Request For Proposal) to manufacturers and starts working with different engineers, subcontractors, etc.
  4. The manufacturer tries to modularise traditional floor plans
  5. If the previous step succeeds, then manufacturers prepare quotations and the contractor orders products (volumetric modules)
  6. Contractor builds the building

Problems

The main problem is that not every floor plan can be modularised. There are a number of reasons - below are just a few of them:

  • Impossible to get the entire building footprint within modules
  • Extremely inefficient use of modules
  • Transportation risks
  • Installation problems

The principal restrictions that manufacturers should respect during modularisation:

Development Projections

  • The developer already built financial projections around this particular floor plan, so the number of units, unit mix, etc., cannot be changed during modularisation. Any minor changes will lead to reconsidering GDV (Gross Development Value) and RLV (Residual Land Value), making current projections wrong.

Architectural Functionality

  • Briefly speaking, the manufacturer cannot change corridors (fire safety requirements), windows (sunlight / daylight calculations), spaces (room area requirements). They cannot divide wet zones into separate modules, leading to difficulties during installation. And, of course, many more issues.

Planning Approval

  • If the project has already passed the planning stage, it creates even more mess around modularisation. Changing footprint, building program, materials, etc., are not acceptable.

In addition to the restrictions above, the manufacturer also needs to work with the following criteria:

Manufacturing and Assembling Efficiency

  • There is an appropriate term - DFMA. DFMA stands for Design for Manufacture and Assembly. DFMA is the combination of two methodologies; Design for Manufacture, which means the design for ease of manufacture of the parts that will form a product, and Design for Assembly, which means designing the product for ease of assembly. As a manufacturer, you don't want to produce completely different modules each time, and also, you don't want to have a lot of different types of modules.

Shipping Efficiency

  • Usually, this is connected with modules restricted by size caused by transportation capabilities and construction site placement and accessibility.

Structural Efficiency 

  • This part is very connected to the building concept (maximum height, loads, etc.). Again, the modules from the bottom and the modules from the top of the building can be the same architecturally, but they will not be the same structurally.

These criteria are all overlapping, so finding the best solution is a trade-off as usual (and multi-criteria optimisation takes place here).

Solution

Fixed Scheme-1

So, the main question is, how can we fix the problems above and find the optimal criteria trade-off? As often happens with multi-role process automation, the first obvious way to fix the problem is to change the process.

Let's assume that manufacturers / contractors could be involved in the flow from the very beginning to explain to architects about the supply chain, products, etc. In that way, architects could deliver building concepts taking into account the nuances above.

The workflow would look like this:

Consultants here are optional, but they can bring a lot of value to this process and organise project participants.

Anyway, as we all know, there is actually no way to change the process. 😉 Only vertically integrated companies can afford such a luxury - to set up operations in such an efficient manner.

There is another way to fix the problems defined above. It is all about an automated modularisation software solution. Such a solution could be used by manufacturers to prepare quick quotations based on traditional floor plans. Unlike the previous approach, this one is more like a hotfix, but it still makes sense for as long as you cannot change the process itself.

At Kreo, we decided to build a PoC (proof of concept) of an automated modularisation software solution. And here I am going to explain what we did with it so far.

We agreed on the input [pdf floor plan] and output [volumetric modular building informational model]. The PoC flow was divided into three main silos:

  1. Floor plan pre-processing
  2. Modularisation (post-processing)
  3. Building concept automation

Let me dive a bit deeper and explain a bit more about all these points:

Floor plan pre-processing

Here we use our pdf floor plan recognition technology from the 2D Takeoff tool. We use convolutional neural networks to segment and classify spaces, walls, doors, and windows. After that, dynamic programming algorithms finetune neural network results to produce final polygons.

Group 8500

As an output here, we get a digital floor plan with quite a few errors and shortcomings. We don't care much about these errors because our next silo will fix them (or overwrite them 😁).

Modularisation

Here we process results from the previous step. We use dynamic programming or open-source constraint programming solvers that suggest the best modular scheme on top of the traditional floor plan. We tried to be focused on respecting constraints (development projections, architectural functionality, planning approval), and we didn't work so much on criteria, so there is no multi-criteria optimisation at the moment (manufacturing and assembling efficiency, structural efficiency, shipping efficiency).

Group 8502

The output of this silo is volumetric module configuration (modular scheme) that complies with restrictions, which means it doesn't change the floor plan.

Building concept automation

When we have a modular scheme, we can actually use the power of our Kreo Modular tool to generate a 3D model of the building with the necessary dashboards.

Group 8509

For the sake of clarity - we will not automate all parts of this PoC until we prove this PoC. By "prove PoC", I mean having enough companies in the market with problems that we solve with PoC and companies ready to pay for such a solution. So, for now, it is just fun research.

Here is a video where all three silos above are glued together:

Thanks for reading! ♥️

BOOK A DEMO

The Kreo Software Blog.