Industrialized construction is becoming a household name within the building industry due to its advantages in improving productivity, quality, accuracy, and efficiency. To succeed in industrialized construction, applying innovative BIM workflows and using advanced technologies through all stages from design to production has been one of Nordic Office of Architecture’s most important strategies.
This article showcases a set of high-end prefabricated housing units. It provides insight into the Scandinavian way of industrialized construction, and how a cross-disciplinary collaboration with the software development team of Project Frog has enabled new possibilities to aid in DfMA and BIM workflows. This collaboration reflects on the challenges that architects and engineers have faced in the presence of repeating information, and provides a step-by-step workflow for similar projects (hotels, schools, office buildings, etc.).
High Performance Housing Development
Nordic is currently involved in a number of high-end housing developments which involve the design of several different residential unit typologies, and their repetition in alternative formations on a range of sites. This type of project deals with similar BIM challenges previously faced, and outlines the potential for a better, more efficient, quality assured workflow.
The residential units are categorized into base types, and their combinations can vary from one house to clusters of four houses. In this case, we will show four base types for analysis: the N1, N2, N3, and N4.
Alternative clusters or arrangements possible on different sites:
In assessing the different possible clusters, it is evident that the only real discrepancies between a house on the left, middle, or right are the conjoining conditions between the exterior walls.
Other than these areas, the residential units are identical (not considering client customization which comes in at a later time).
Within each design base type, there are several configurations available which include additional elements and certain deviations (carports, basement levels, extra windows or doors, longer base plans and terrace levels) which we call the subtypes. In analyzing the design at both a base type level and subtype level we can see a high level of design repetition, an identified potential for modular construction and subsequently an improved BIM process.
The usual BIM organization of these types of projects is chaotic. If you can imagine several architects involved at different times and with different developments, some for the design of the isolated residence base and subtype designs, others the clustering of housing on particular sites, and then others responsible for the customization of the residences to suit the particular site and client.
Without well-organized data routines, a lot of repeated work and wasted time occurs where some team members are using groups or design options, with others preferring links. Mirrored and unmirrored...
The standard out-of-the-box workflows also do not allow for an appropriate level of detail at each phase to suit this type of project. After the development of the initial types, the combinations are then conceptually placed in subdivision formations and it is beneficial for us to show volumes here in these early phases. Ideally these volumes would act as placeholders for the developing designs which can be worked on simultaneously in another arena or file. In many situations, we are required to change between a volumetric design and a detailed design to show the right information at the right time.
In approaching the team at Project Frog to discuss our project and the potential for kit connect to adapt to the demands of our proposal, we had the following wish list:
Ability to show both volumetric representation and detailed design in the same arena
One source of truth: one place where we know the information is correct and up to date
Break down the residential units into master modules and be able to create deviations or presets that were intelligent in the way they would be update-able
Allow the potential for modules inside modules (residential unit = module, and groups of components inside module can also be modules)
Potential to create quantitative totals, price, and C02 emissions
Ability to work on the same modules from design through to construction (contractor involvement)
Some things on the list were already possible and others would require future development. In approaching the client, we proposed a methodology for assessing the project based around these focus points:
How can we save time on drawing things that are duplicated and be sure that the information is the same in every entity?
How can we better manage deviations inside duplicated sets of elements?
Can we prepare the model in a way which saves the contractor building up a new model for construction?
How can we align our model to the way the project will be constructed – proposing modular.
Analyze–Find opportunities for taking advantage of duplicated design and identify areas that could be considered for industrialized construction or modulation.
Systemize–Divide the different packages which were a result of the analysis phase. Find a robust system that can cope with eventual changes and developments in the project.
Categorize–Make a code system that can be used to describe the duplicated design or industrial packages, and which can tolerate new types and deviations.
Test phase–Integrate and test proposed methodology for improving project workflows associated with design repetition and industrialization. (In this case, new technology, kit connect, for the cloud-based handling of geometry and data.)
Summary–Compare the new workflow with the original workflows used previously and evaluate to form a list of pros and cons. Conclude and recommended way forward.
In the analysis of the N1, N2, N3, and N4 base types we could see repetition in layouts and the potential for optimzing construction methodologies.
As each base type could conform to four different subtypes, we analyzed the four subtypes of one base type (the N4) and aimed to be able to provide the same strategy for the other base type examples. In comparing the N4 sub types we could begin to configure a potential breakdown of repeating and potentially industrialized parts, that we could capitalize and align to using BIM.
The modules were separated by their potential to be industrialized or simply just act as repeated design. The modules where also chosen both because of their size (what can be transported from off-site factories) and adaptability to be used in other N housing layouts.
The modules chosen were:
Shell–Separated on the first and second level; potential for penalization stair; could be prefabricated off-site
Bathroom–Cross-disciplinary pod built off-site
Interior–First and second floor separated, design repetition
Carport–Evident in the N1-4C subtypes
Basement–Built on-site, evident in the N1-4K sub types
Roof–Three variations: tilted roof, A pitch roof, terrace roof
Important factors here were that the different modules could be used across base types, and that we would have the ability to update one module and then choose to automatically update all the other base and subtypes.
The next task was the systemization and categorization of the system so that the concept would show to be robust in all combinations and deviations.
A coding strategy combining the module name (and level if appropriate) with orientation ‘left’ (the type), the size of the module (‘standard’, ‘large,’ or ‘small’), and any deviations, for example an extra window, or any other type of component.
After the system was in place, we could begin testing by first publishing all the elements as parts into the cloud-based library before publishing the modules. System types (most but not all) and family types can be published. It is important to be aware of which elements and categories can be published before considering elements for modules.
It is important to also ensure the models are drawn in a way which enables the modules to be isolated; that is, disallowing joins where appropriate and ensuring all components that need to be published exist. A zero point strategy also needs to be considered. Each module will contain a relationship to a zero point or insertion point, and this should be placed at a location that will remain constant. An example of this is at the corners of framing. Modules can be swapped in and out relating to this point.
When the module is ready for publishing, the below workflow outlines kit connects main concepts of development. The modules are hosted in the cloud and can be shown in 3D or reduced to a bill of materials. The module is then available for use in other projects and formations and when updated we can inform multiple buildings simultaneously and be 100% sure we are presenting the same module in each design. Once hosted in the cloud, those with the correct access can pull the module into the module editor and add their discipline geometry.
Below you can see the creation of the S01 module (shell level 1 module) and its subsequent presets or deviating shells. These presets take into account the changes needed where the module sits at a left, middle or right position. The windows and doors are shared so can be swapped out or turned on and off in the preset modules. A robust coding strategy ensures that others can understand the populated library of modules.
You have two different ways of viewing your modules in the project—as a conceptual volume or as a detailed module design—and this means you can go back and forth depending on what your project delivery requires.
In the future, we are also hoping for quantitative information to be present as attached quantitative data for example C02 emissions. Any occurring deviations can be taken up in additional presets using the coding strategy to ensure others can understand the populated library.
After all modules and presets were published to the cloud, we could run a test assembly of a project we already had on file. For this project we needed seven modules and six additional presets.
After the testing phase, it was important for the client to understand why the current working methodology did not meet up to our expectations and compare those routines with kit connect. Comparing our wish list and the focus area for the testing process we mapped the comparison of the use of links, groups, design options and kit connect. The result showed that kit connect covered many more aspects of our desired workflow than any out-of-box tools.
Summary: Practical Tips and Tricks
1. Important factors to consider: coordinating the edges in which a module meets another module or any other geometry
2. Areas of potential change: try to predict any possible alterations, this will save you having to re formulate your coding strategy
3. Features: not all our desired features are available, but we are looking forward to a potential release of more system families being able to be shared, a module within a module, and quantitative calculations
4. At the moment the volume to detail change is module based, if it could be that modules could be imbedded in modules the residential unit could be a volume on its own
Software Developers’ Perspective
Data and Discovery with Customers in I.C.
1. Gathering and categorizing this data has defined KitConnect and its path
2. Discovery process unique (not limited) to:
a. I.C. process = accommodate company workflows and project specifics, etc.
b. I.C. process = what will be fabricated offset, the logistics of fabrication, assembly and VDC/DfMA workflows, etc.
c. Company workflows = what are the required internal BIM workflows, etc.
d. Project specifics = timelines, delivery methods, client requirements, file structure, BIM workflows, how will collaborate be dealt with, etc.
How to Begin
1. Create a KitConnect Project
2. Assign users to the project
3. Connect Revit files to the project
Build Your Content
4. Publish, arrange and apply rule sets to your content
Use Your Content
5. Use and edit your content in Revit projects
The collaboration with the programing team of COWI and the software development team of Project Frog reflects on the challenges that architects and engineers have faced in the presence of repeating information.
One of the crucial things about developing technology is that we must start with the project team’s needs and then work backwards to the technology. We cannot start with the technology and then try to figure out where we are going to put it in our project. If we can only use one or two programs to overcome the challenges and one or a few clicks to rule it all, why do we need more?
We have chosen to unite with the programmers and software developers to overcome the defined challenges in our projects. Starting from the New Stavanger University Hospital project and then developing further for housing projects, our workflows and the experience of collaboration are highly recommended for similar projects focusing on industrialized construction, modular design, and repetitive layouts (hotels, schools, office buildings, etc.).
Soren Shen-Lung Lin completed his second master’s degree in Built Environment at Royal Institute of Technology in Stockholm in 2007. He is a qualified architect and specializes in built environment analysis and industrialization methodology. He is passionate about applying innovative methodologies and advanced technologies to large-scale projects. In Norway and abroad, Soren has worked on different large-scale projects including New Stavanger University Hospital, LHL Hospital Gardermoen, and Oslo Airport T2. He was one of the key specialists creating the industrialization methodology for the New Stavanger University Hospital project which won Autodesk’s AEC Excellence Award in 2018.
Bridget White is originally from New Zealand, and completed an honors degree in Architecture at Victoria University in 2006. After beginning her career working in New Zealand, she moved to Norway to start at one of the country's largest practices, Nordic Office of Architecture. She is a senior architect, BREEAM AP, BIM manager, and BIM coordinator for large-scale airports, hospitals, schools, national governmental facilities, and transportation hubs. She is the leader of a team of experts at Nordic using a wide range of Autodesk products and implementing new office workflows involving complex analysis, virtual reality, industrialization, integrated sustainability, and streamlining the flow of information between architects and the building industry.
Joining Project Frog in 2014 as the BIM manager, Steve DeWitt has 20 years of experience in design software and is a certified Autodesk Revit professional. His current focus is the development, utilization and implementation of KitConnect both internal and external to his company. Steve is a contributor to several AEC groups such as SF Computational Design Institute, Revit user Group (all over the United States), TAP’s, and Autodesk University. His recent position has allowed him to explore everything from how Revit can drive CNC machines to how Forge can drive intelligent collaboration methods.