Workflows and the ‘why’ of it all
The first month or so of working with the ilke Homes team involved a few failures. We explored areas where we had solved problems before, however the return we would get from our efforts didn’t fit with ilke's significant aspirations. For example, automatically driving a Revit services file to align not just MEP openings but all services equipment to certain design conditions. Sounds very useful but it worked against the internal sign-off process and was going to need a major change in how QA was carried out, so we moved on.
We have the best team around for solving the 'how' of complex design logic problems, but we need to understand the ‘why’ first. After those early attempts at automating some of what the team did, we settled on the premise: ‘Well, let’s do all of it. Let’s automate everything you do after you complete the design of a house.’
Before we addressed workflows, we decided as a group; that models used for the production of the ilke modules should be closer to those used for manufacturing than for design. Revit is a great design tool but tends to treat things like walls and floors as monolithic elements and not respect their complex build-ups and component parts.
We did not want to disrupt the design process for new house types too significantly which meant maintaining a Revit file for design in a way many of you would be familiar with as shown above. We needed to convert that content directly to the type of elements required for fabrication. The first few workflows focused on the panelisation of the boarding used in the modules, coupled with the fixing requirements and penetrations for services. An individual ilke Homes module has a limited amount of purely-repeated materials/processes, but across all the modules being produced, the efficiencies found in automating panelisation, openings and fixings was significant and warranted the focus.
The possibilities of automation were huge but it also solved the problem of translation from Revit to Inventor, from design to manufacture. The ‘why’ was now clear. The ilke processes repeat hugely across house types, the scale of time and resource savings grow directly in line with the growing output of the business.
Logic and learning the basics of MMC
The first thing that became abundantly clear is that when the modules are put together in the factory, the main driver for most decisions is the steel frame. So our first step was to make it the centrepiece of the work. We were fabricating a complex steel frame volumetric module, not a traditional house. So the adjustment needed to be clear in the design information such as the Revit files.
With the scope of our partnership covering the vast majority of post-design processes, we began the incredibly involved task of uncovering the ‘how’. How does this group of experts put their homes together? Why are these dimensions, rules and methods chosen? What can be done to articulate them?
The act of codifying a rule can be quite simple. Let’s say a typical panel of plasterboard is not more than 1m wide and not less than 300mm wide. Now we have our maximum and minimum. But… let’s say that the minimum is 350mm in the specific scenario of being a removable panel in a corner. Now let’s say that the inside corner doesn’t have this rule, but the outside does. Let's say making one panel optimum makes its neighbour too small and you need to start again. It gets complex really fast.
Now multiply that by all the panels, fixings, furniture, fixtures, framing and lifting elements, and you have a wild web of interlocking rules.
To give an understanding of the complexity, let's take a quick look at one isolated workflow. The creation of fixing points on panels to tell the machine where to nail to boarding to the steel frame. The headline rules are:
As the team at ilke studied the structural requirements to find optimisations, we went ahead with laying out the algorithms required to lay out that fixing patterns taking into consideration where in the module the fixing would go. We did not want the team to have to action a separate workflow for each zone, each time. This process ended up being one of the most difficult primarily due to overlapping and sometimes contradictory requirements. The modules are complex and panels have a wide array of conditions. So a rule for Side A/ Zone 2 may contradict that is required to an access hatch being in the same space. Those contradictory needs had to be codified.
It looks very simple when finished but it really is not.
After months of learning and codifying the ilke Homes construction rules, we had a solid set of workflows that turned a baseline Revit design model into one aligned to the processes on the factory floor.
Another stage in our education began with the ilke team showing us why certain parts, that we believed adhered to the rules, were not optimal and needed to be reworked. For the team to actually deliver on their promised new homes, we needed to make sure everything was practicably buildable. Every panel, every screw, every opening had to be checked to make sure it could be created in the expected way and not have knock-on effects for later production efforts.
We wanted to avoid only partially automating the process, so we revisited much of the code we had built to take this into account. As the ilke team did their virtual prototyping, we made changes to how our technology understood framing, positioning and sequencing.
We had what amounted to a digital replication (at least in the geometric sense) of a module. Every bit of plasterboard, OSB, insulation and fixing, across all walls, ceilings and floors digitally represented.
Now we had to get it built.
During the time we were discovering how to automate all of the cut plasterboard, we realised there were enough similarities to help us solve a façade design issue we were experiencing with a large designer client. The concept of turning these business rules into logic only really works for the company engaging in their complete creation. But what was hugely exciting was that we were learning how to articulate the questions consistently. That consistency meant we could have a speedy engagement on a fundamentally different type of construction and benefit from knowing what to ask and how to integrate the answers we received.
In Part 3, I will cover how we brought multiple projects together and then tackled the drawing and outputs automation. A gigantic task in itself but one enabled by the fact we were creating our own geometry in a consistent and pre-planned way.