LEGO Architecture meets BIM – Part 06: An OPEN BIM data structure

Introduction

This is the 6th in a series of posts about “LEGO Architecture meets BIM”. In the previous posts we have focussed on the geometry of the model for the Villa Savoye building. A Building Information Model (BIM) however also involves the important part of BIM, the ‘I’ which stands for INFORMATION. This is a crucial difference from a model that is simply been built to show a design in 3D.

Models that use a BIM approach should have a clear consistent data structure. There are two ways of approaching the data structure. Firstly a model can use a native data structure which relies on fields of data within a particular authoring tool. The second is to structure the data around a standard. For us that data structure is ISO 16739:2013. This ISO standard means that data from models, whichever authoring tool they use can be structured in the same way. The main reason for using this approach is it means that data can be transferred from one solution to another without the need to create mapping for every model, from every tool and which could be different from every author. Using a native approach simply introduces waste into the process of creating BIM in my opinion.

Many people also see open data structures as something that is used solely at the point of export from authoring tools. Yet consistency from authoring tools with all other tools is also an important part of our industry using and understanding these standards. We want users to understand data in other tools, not just the authoring tool, so having consistency between all tools is a logical approach and therefore our internal processes are aligned against these standards. We will see in future posts how the data created in our authoring tool can be viewed and utilised in so many other ways.

So for the LEGO project we have built the data structure to align with ISO 16739:2013. In addition we have incorporated the requirements of BS 1192-4:2014 and the NBS BIM Object Standard. Of course there is still a need to add some project specific data fields, particularly for this project as its LEGO! Some additional data has been added and this is noted below accordingly.

This posts sets out in detail the structure and data content of the model. The primary aim of this post is to show how a model is arranged, the types of DATA that can be created at each level and the example DATA within this model. In future posts we will look at how we can turn this DATA into INFORMATION that can be useful to various parties in the design, construction and operations process.

Note: The data set out here is produced in GRAPHISOFT ARCHICAD 20 and other tools will vary slightly in how this data is set out. Some authoring tools will only produce this structure and data at the point of export but the important thing is that any authoring tool should be able to create these consistent open data structures.

---

A. MODEL DATA STRUCTURE

A1. Model Data Structure Overview

The following is an overview of the model data structure for the LEGO project:

Image: An overview of the model data structure (click to enlarge)

1. Data at the BLUE levels is not physically attached to any geometry within the model.
2. The DARK GREY data is data that is attached to a physical object in the model, either a modelled Space or Component/Element.
3. The PURPLE data again has no physical geometry but instead Spaces can be allocated to Zones whilst Components/Elements can be allocated to Systems. These are called an IfcAssignment under ISO 16739:2013. For the record, assignments can also be created for IFC Groups, Actors, Space Occupants and Time Series Schedules.
4. The ORANGE data can only be created after the geometry of Components/Elements has been created (this is a specific ARCHICAD workflow, other tools may vary).

A2. Project, Site, Building, Floor (BuildingStorey), Space and Component/Element Relationship

The relationship of IFC is often displayed in various tools as a tree. At the top level is Project followed by Site, Building and Floors (Building Stories). Spaces and Elements (or sometimes called Components or Instances) are then connected to the Floors (in IFC these are typically each called an IfcBuildingStorey).

An IFC file will only ever have one building per file so multiple buildings would mean multiple files.

This model contains 1 Project, 1 Site, 1 Building, 4 Floors (BuildingStories), 10 Spaces and 659 Components (plus one non-modelled Component). Note: It also contains 3 Zones, 99 Types and 11 Systems which are not shown in this tree below.

Image: Project, Site, Building, Floors (Building Stories), Spaces and Component data structure (click to enlarge)

A3. Component/Element and Type Relationship

Components/Elements that are the same form a Type. In the example below you can see a number of Components/Elements placed under their respective Types. Data can be added to the Component/Element (which has physical geometry) or at the Type level (no physical geometry) where data is the same for all the identical Components/Elements.

There are 99 Types in this model. There are 96 Object Types and 3 Space Types.

Note: There are 97 Object Types in the full LEGO Architecture set but the model excludes the Element Separator (4654448) as this piece is only used to deconstruct the model.

Image: A partial example of how Components can be listed under the Type level (click to enlarge)

Image: A list of the model Types – excluding SpaceTypes (click to enlarge)

A4. Component/Element and System Relationship

Components/Elements can also be associated to a particular System.

There are 11 Systems in this model. Each Component (659) is allocated to one System. They are split as follows:

• Bricks – contains 145 Components
• Bricks With Bows And Arches – contains 14 Components
• Bricks, Special – contains 7 Components
• Bricks, Special Circles And Angles – contains 1 Component
• Bricks, Special Hole And Connecting Bush – contains 2 Components
• Bricks, With Slope – contains 10 Components
• Frames, Windows, Walls And Doors – contains 12 Components
• Plates – contains 435 Components
• Plates, Special – contains 13 Components
• Signs, Flags And Poles – contains 16 Components
• Technic Connectors – contains 4 Components

Image: Components are related to relevant Systems (click to enlarge)

A5. Zone and Space Relationship

Zones and Spaces have a similar relationship to Component/Element and System relationship.

There are 3 Zones for the LEGO model. These are split as follows:

• Circulation Zone
• Hanging Garden Zone
• Internal Zone

Image: Spaces are related to Zones (click to enlarge)

---

B. MODEL DATA

Below we have set out in detail the data that can be viewed at each level within the model:

B1. Project

The following data has been added that is not identified in any of the standards noted previously: All properties under Additional_Pset_Project (11 properties) and Additional_Pset_Template (4 properties).

Image: Project information (click to enlarge)

B2. Site

Image: Site information (click to enlarge)

B3. Building

Image: Building information (click to enlarge)

B4. Floors (Building Storey)

Image: Building Storey / Floor information (click to enlarge)

B5. Spaces

The following data has been added that is not identified in any of the standards noted previously: All properties under BBA_Pset_General (1 property).

Image: Space information (click to enlarge)

B6. Zones

Image: Zone information (click to enlarge)

B7. Types

The following data has been added that is not identified in any of the standards noted previously: All properties under Additional_Pset_TypeGeneral (1 property).

Image: Type information (click to enlarge)

B8. Components/Elements

The following data has been added that is not identified in any of the standards noted previously: All properties under Additional_Pset_Lego (13 properties) and Additional_Pset_General (1 property).

Note: The data view below varies slightly to the others. This is because the model uses a combination of native and IFC approaches to produce a valid IFC file. However the native data (available in ARCHICAD 20) can be created in such a way that it is essentially the same as using the inbuilt IFC fields. There are some advantages of using this native approach which we will discuss in a future post.

Image: Component/Element information (click to enlarge)

B9. Systems

Image: System information (click to enlarge)

---

Advice for clients

In the last post we noted that clients should ask for 3D models from consultants. However if a client wishes to pursue a BIM approach then they must also seek consultants who will be able to provide the DATA element of models. In order for consultants to provide the right data it is important for clients to set out their detailed data requirements. This would typically be identified in an Asset Information Requirements (AIR) document. These detailed requirements can then inform the development of an Employer’s Information Requirements (EIR) document.

The EIR (along with the AIR) will allow consultants to understand the requirements of their clients and assess how much work will be involved in delivering these requirements. Consultants can then be requested to provide a Pre-contract BIM Execution Plan that will set out how they intend to deliver these requirements as a company (or a company including their supply chain). This process is part of the UK Government approach for “BIM Level 2”.

Many clients fail to set out their detailed requirements and only request “BIM Level 2”. Without the information requirements then a project can not achieve “BIM Level 2” and is likely to lead to clients not receiving information that will be useful to them. In future posts we will look in detail at how the above data can be turned into INFORMATION.

Rob Jackson, Associate Director, Bond Bryan Digital

Terms and conditions

This policy is subject to change at any time.

LEGO and the Lego logo are trademarks of the LEGO Group. Any trademarks, service marks, product names, corporate names or named features are assumed to be the property of their respective owners, and are used only for reference, without intent to infringe.