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:

Screen Shot 2015-12-23 at 18.30.45

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.

OPEN data - Overview

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.

OPEN data - Type and Component

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

OPEN data - Types All

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

OPEN data - Systems All

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

OPEN data - Zones

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).

OPEN data - Project

Image: Project information (click to enlarge)

B2. Site

OPEN data - Site

Image: Site information (click to enlarge)

B3. Building

OPEN data - Building

Image: Building information (click to enlarge)

B4. Floors (Building Storey)

OPEN data - Floor

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).

OPEN data - Space

Image: Space information (click to enlarge)

B6. Zones

OPEN data - Zone

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).

OPEN data - Type

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.

OPEN data - Component Element

Image: Component/Element information (click to enlarge)

B9. Systems

OPEN data - System

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

linkedinicon4

Terms and conditions

All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. Bond Bryan will not be liable for any errors or omissions in this information nor for the availability of this information. Bond Bryan will not be liable for any losses, injuries, or damages from the display or use of this information. 

We are happy for others to share our blog pieces through all social media platforms. You may include links to the original blog pieces and use part of the blog to then provide a link to the original content. However we would appreciate it if the content is not reproduced in full on other sites or publications without written consent being granted by Bond Bryan.

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. 

This post has been viewed 2049 times.

2 thoughts on “LEGO Architecture meets BIM – Part 06: An OPEN BIM data structure

  1. Intresting article. But why you put all information in the model? Is that useful for the daily work in AC? The information can be also in a database. Then you cross the graphic and the data in navisworks…

    • Hi Christof,

      The project is an example of how data is structured. This is obviously not a real project and is only there to show how data is structured in IFC and also in later posts to show how this can be used. However much of this data would be the same as a real project with the exception of the LEGO specific attributes. Many of the fields are placeholders and these are required for COBie for example for others to complete in external databases.

      Rob

Leave a Reply

Your email address will not be published. Required fields are marked *