Building Information Modelling

(1)

Building Information Modelling

The Digital Plan of Work & Assemblies

5 March 2013 DRAFT ONLY V7-1

(2)

Version Control

Version 0-6 2012

Various Authors for comment

Version 7 28/2/13

Issue for Comment and Information on www.bimtaskgroup.org/labs

Version 7-1 5/3/12

(3)

0

PART 1 – The “Plain Language Description” ... 1

Participants in the Preparation of this Document ... 1

Introduction ... 2

Background ... 3

Assemblies & Assembly Management ... 7

Commercial Issues ... 8

Context of the Government’s Construction Strategy ... 8

Government Soft Landings (GSL) ... 8

Standard Procurement Routes ... 8

Alignment of Procurement Strategy and BIM ... 8

Precedence of Contract Documents ... 9

The BIM Protocol ... 10

IP and Copyright under the BIM protocol ... 11

Practical issues associated with Levels of Detail ... 11

Role of the Employers Information Requirements EIRs/CIRs, including definitions of Project Outputs ... 13

Production of Commercial Data ... Error! Bookmark not defined. Digital Plan of Works ... 15

The Plan of Works ... 16

Project Hierarchy or Data Types ... 16

Materials ... 16

Objects (Components) ... 16

Assemblies ... 17

Project ... 17

Example of Project Hierarchy or Data Types ... 17

How does the Data Hierarchy Relate to the dPoW? ... 18

Defining Digital levels of Details ... 25

Checking Data ... 25

Managing Specification Information ... 28

Example of Specification Application ... 29

PART 2 – Technical Definitions & Specifications ... 32

Grouping of Component Occurrences ... 32

Systems ... 32

Assemblies ... 32

The Issues ... 33

COBie Representations of Assemblies ... 35

IFC representations of assemblies ... 39

Checking For Compliance ... 39

Introduction ... 39

Compliance, Continuity and Completeness ... 40

Compliance ... 43

Completeness ... 45

Demand Matrix ... 47

Supplementary Demand Matrix ... 48

Glossary ... Error! Bookmark not defined.

(4)

The “Plain Language Description”

1

PART 1 – The “Plain Language Description”

Participants in the Preparation of this Document

The production of this document has been a truly collaborative exercise with input from many parties especially the project team on the MoJ Cookham Wood project which was the BIM Task Groups first early adopter project.

Other input was provided by (in alphabetical order)

AEC3 Ltd BIS Bryden Wood Ltd Cabinet Office ECS Ltd HA MoJ MR1 NBS RIBA

West One Management Consulting

Important note: This draft manual and the downloads available from the ‘Labs’ area of the BIM Task Group website are for educational use and comment only. They are not yet available for production use. Please comment at

(5)

The “Plain Language Description”

1

Introduction

The purpose of this document is to clearly document the concepts and detail of the management of built asset data derived from the process of building and managing building information models. The focus brought about by the requirement of the UK Government to mandate BIM Level 2 deliveries on all publicly procured assets by 2016 has necessitated clarity as to how this data is defined, tested and effectively used by both the supply chain and the public client, this document sets out to deliver that clarity.

As well as delivering supply chain definition we also seek to deliver a consistent requirement to the industry institutions that provide assistance to the market through their publications of “Plans of Work” and “Scopes of Services”. The advent of clear data requirements brings many opportunities for value creation in the industry and it is our intention that this document will aid understanding to encourage others to seek and capitalise this value.

The requirement for these documents was identified during the development of the original strategy as was the need to define matching new classification systems such as Uniclass 2 which is also described in this document; these are described in figure A taken from the BSi (B/555) Roadmap created in conjunction with the BIM Task Group. In summary this document sets out to describe the methods needed for clients to procure data from the supply chain for very specialist users and to check it has been delivered. It does not set out or aspire to enable better quality design in itself but merely ensure data is available to enable better design.

This document is issued as a draft with the example model, demand matrices and validation tools to assist in the practical understanding and management of

construction data. It is our intention to shape the future production digital Plan of Works through this process.

CAD 2D 3D BIMs iBIM A I M B S I M F I M S I M B R I M CPIC AVANTI BS 1192:2007

User Guides CPIC , Avanti, BSI

ISO BIM

Drawings , lines arcs text etc. Models, , collaboration

IFC

IDM _IFD

Integrated , Interoperable Data

Level 0 Level 1 Level 2 Level 3

objects Standards Guides Classifications Delivery BS 1192:2007 BS1192 :2 CAPEX

Building Information Management : inc Guide to BS1192

Guide 1 Guide 2 Guide 3

CPIC Uniclass/CAWS

CPIC RIBA/ACE/BSRIA Plan of work Includes contractual and level of detail

Increase level of detail and content as lifecycle knowledge grows New classifications to assist lifecycle delivery BS 7000 : 4 BS 8541:2 BS 8541:1:3:4 BS1192 :3 OPEX IFC IDM IFD

(6)

The “Plain Language Description”

1

Background

As the construction project progresses there is an accumulation of data, derived through the normal design and project development process. As new tools and techniques develop, including the arrival of Building Information Modelling (BIM) the need to manage both “digital data” as well as “geometric data” has become better understood. The introduction of some technologies such as e-mail conspired against our ability to manage for some years but well thought through “Standards” such as BS1192 and its BIM Level 2 brother PAS 1192:2:2013 have striven to gain control of the task. The whole life of an asset through both its “Capex” delivery phase or its longer “Opex” operational phase can be though of as cyclical process, indeed this is the approach adopted by PAS1192:2:2013 and Figure 1, reproduced from the same document indicates this cycle.

COMMON DATA ENVIRONMENT (CDE) BIM Execution Plan

(BEP) Master Information Delivery Plan (MIDP) EXECUTION DELIVERY EMPLOYER’S DECISION POINT SUPPLIER’S INFORMATION EXCHANGE Graphical Model Non-Graphical Data Documentation

Project Information Model (PIM) Asset Information Model (AIM)

MAINTENANCE and USE (PAS1192-3)

For details on supplier’s information exchanges and employer’s decision

points see CIC Scope of Services

1

CONCEPT

2

DESIGN DEFINITION COMMISIONBUILD &

HANDOVER &

CLOSEOUT OPERATION IN USE

3 4 5 6 7 BRIEF 1 PROCUREMENT CONTRACT AWARD 2 3 6 7 1 2 3 4 5 6 7 n Employer’s Information Requirements (EIR) NEED Legend

Green Blue Management Process Information Process STRATEGY Opex Start Capex Start

Figure 1 - The information delivery cycle (PAS1192:2:2013)

To deliver the vast amount of information the project generates through its lifecycle a number of organisations are employed to work together to deliver the “contract” or agreement between the employer and the supply chain. Normally this is through a prime or main contractor and his supply chain during capital delivery and a maintenance or facilities management (FM) supplier during operational phases. A client may often engage a number of design professionals at the early stages of the project to assist with the process of developing a brief and developing a design to a stage where it can be taken to the market to establish the method or procurement. There are as many methods are there are views on procurement and this document does not seek to recommend any particular route but does adopt the general direction of UK public procurement for early contractor involvement (ECI) as well as cost (benchmark led) and the use of NEC target cost collaborative approaches. This document seeks to explain how this new ‘digital’ data is procured at ‘Level 2’ (REF www.bimtaskgroup.org) to enable clear definitions of need to the supply chain and use full data detailed to the client for use.

(7)

The “Plain Language Description”

1

Figure 2 – Supply Chain Tier Model

The illustration in figure 2 demonstrates the key project relationships with the tier one column occupied by the suppliers directly contracting with the employer. The selected supply base supplying data up to the tier one who is responsible for its coordination use and submission to the employer must be employed consistently to ensure data can be created and re-used, rather than repeatedly re-typed.

Clearly it is incumbent on the employer to only ask for information that is needed at each stage of the project. Currently this requirement is articulated in a number of documents including the various “Plans of Work”, “Scopes of Service” and “Duties”. These documents are all input specifications which seek to describe what should be done at each stage of a project in a rather generic way. It makes the process of work measurement very difficult and has spawned many new (over forty) approaches all attempting to fix the problem of work definition, measurement and ultimately payment. The addition of actual project “data” to this equation as well as traditional geometry (as required at BIM Level 2), a new approach is clearly required.

The approach taken by the BIM Task Group has been to look carefully at the client organisations in the public sector. Clearly the Level 2 programme is five year years in duration and there is much to be learnt but the careful selection of both a building and civil engineering (infrastructure) departments early in the programme has enabled us to form clear generic definitions which will be refined as each department joins the adoption process. We have analysed the data requirements of each client and developed a series of client delivery process charts some of which are available at

www.bimtaskgroup.org for reference. On these process charts we have identified the

key decision points each client makes and what the “Plain Language” Questions are that the client is asking to make those key decisions. These are illustrated in Figure 2 by the red diamonds.

During 2012 the BIM Task Group brought together a group representing a wide variety of institutions and organisations with a view to creating a coordinated plan of work. The new plan of work will be based on a series of numbered stages 0 to 7 which will encompass the whole of a project lifecycle, from identifying strategic need (at project or portfolio level) through to operations and end of life.

(8)

The “Plain Language Description”

1

The naming of these stages is not building specific, but will also apply to infrastructure

and civil engineering projects providing a consistency across the whole of the construction sector. The naming of the project stages is therefore agnostic with regard to project type.

0. Strategy 1. Brief 2. Concept 3. Definition 4. Design

5. Build & Commission 6. Handover & Close Out 7. Operation & End of Life

Each of the institutions will be engaged with a view to developing their own plans of work in line with the new project stages, complete with scopes of work and levels of detail.

As the project progresses the data “Progressively Grows” as originally documented by Phil Jackson in his ICE paper. The rate of this growth must be driven by the amount of information needed to answer each Key Client Question. Any more and we are incurring waste, any less and we cannot effectively answer the questions. These questions are known as the ‘Plain Language’ Questions.

Figure 3 shows how the maturity or “level” of data can be plotted against time (Plan of Work).

The definition of this data maturity is defined by

1. Level of Detail – The level of geometric information a model should exhibit 2. Level of Definition – The Level of data maturity a model data set should exhibit The measurement of geometric data will continue to be rather subjective during the Level 2 journey, but with data definitions documented at the appropriate level it will be possible to validate data deliveries electronically as they are delivered. This

validation process will be described in detail later in the document.

1 2 3 6 7 N N N D a ta & G e o m e tr y M a tu ri ty Project Stage

Capital Delivery Phase Operations & Maintain Delivery Phase

0%

100% Operational

Decisions

Figure 3 - Plan of Work Vs Level of Detail

In some cases, the level of development of a particular discipline’s model may advance to a greater level of detail development than that of others. However, where this happens it often introduces constraints for other disciplines and risks of either

(9)

The “Plain Language Description”

1

limiting options or innovation and reworking designs if the more detailed work needs

to be revisited.

Putting too much information into the model too soon may restrict both the design and supply chain options for others in the team and leads to other forms of waste with the inherent costs incurred by both the supplier and the client. It also places constraints on the supply chain to offer compliant alternative designs, offering better asset or value performance.

Examples of the former might be detailing a heating and ventilation system or a bridge strengthening structure before the range of design options has been explored and evaluated. An example of the latter be the inclusion of cladding to floor interface details that may would make pre-assembled panelised systems non-compliant or drainage details that rule out the subsequent design of a sustainable urban drainage system.

Too much detail can also reduce productivity and create waste during the design process in that large models require more processing and longer file transfer times. On a large project the model can become unmanageable and may need to be sub-divided. This will be exacerbated if more information is included than is needed. It is therefore essential that an appropriate level of detail be used at each stage. As models are built up from objects that represent the components in the constructed facility, which are increasingly sourced from libraries managed by third parties, it is important that corresponding standards of detail are used when building up such libraries.

In this context it is important to differentiate between what is needed by designers in the early stages, for example volume information, or, a degree of flexibility on how it will look in the model, 2D and simple 3D geometry etc., compared to at the production

and installation stages that will be more demanding. It is also worth considering that a client may ultimately be combining models for a programme, a transport or utility network or a campus. In this context they may need simplified information in order to keep the combined model manageable. Library objects will therefore need to cover a range of requirements. Even if more information is available from manufacturers or the specification, it is not appropriate to include it before it is needed. Figure 4 illustrates an example of how such information may develop and be transferred to the client or archived for future reference, subsequently being updated as the facility is modified later in life.

(10)

The “Plain Language Description”

1

It also illustrates the relationship between the individual (federated) models managed

by different designers or suppliers which are consolidated into a model for coordination purposes and used to provide the information for decisions by both suppliers and, using the COBie format, the employer.

It is assumed (for simplicity of illustration) that the specialised models used for performance simulations or to design ancillary aspects of the project are coordinated through the inclusion of the relevant information into the primary models.

Similarly, to ensure that the project is being delivered in a lean way, it is assumed that information is sourced from the primary models in order to build the specialized models. The duplication of such information contributes to the columns indicating more information content in the right hand column for a given stage. As a general principle, duplication and detail should be minimised to that required at each stage. The “7 - In Use” stages show the incorporation of the project information into the operational facility management system and a database for managing geometric, parametric performance and associated document based information. It also shows a large amount of archived information that may be recalled for reference by future projects, or if need be, to resolve any issues should the building not perform as specified or designed.

Assemblies & Assembly Management

The management of assemblies using Building Information Modelling tools is seen as an essential part of not only the effective adoption of the technologies, but more importantly a key departure from the traditional bespoke methods of delivery that have predominated the UK industry. The principles of assembly management will enable the concept of “mass customisation” and give easy opportunity to integrate

with off site manufacture or supply through commodity or bespoke supply chains as appropriate. The purpose of this document is to explain and document how the requirement, commercial controls and technical data standards and processing are brought together to deliver this capability to the market.

The definition of the attributes of an assembly (the data that describes it) are traditionally documented in a number of locations, with paper documents and relatively simple geometry this has led to ambiguity and confusion with respect to documents potentially contradicting and the need to further protocols to describe precedent and other details. It is clear that as soon as we apply structured data and the need to validate such data for key processes the traditional approach will not be appropriate due to the levels of complexity and accuracy needed.

The management of Assemblies affects the reuse of common components in a Building Information Model. It may seem an essential element of the widespread adoption of BIM from briefing through detailed design to product selection. Assemblies enable the reuse of standardised design or specification elements improving productivity and accuracy of design and delivery as well as providing a location to hold specifications and lessons learnt in a simple and useable way. They may also hold benchmark data for cost, carbon and other impacts. Assemblies are also important in the adoption for DfMA (Design for Manufacture and Assembly) and Offsite construction practices.

Assemblies may represent predesigned elements such as

Standard detention cells

Class rooms

(11)

The “Plain Language Description”

1

Serviced pods and other prefabricated solutions

Bridges or other structures

Other elements

Assemblies may contain a variety of components including walls, floors, finishes, rooms, spaces, furniture, fittings, MEP and structural components. Assemblies are made up of Components which themselves have attributes and classifications. These properties may include key data which is attached to the object for use once it is placed into a model and may include cost, CO2, programme, maintenance and other key information.

Commercial Issues

Clearly the process of procuring an built asset is a significant technical challenge. This is matched only by the commercial controls that need to be put in place to manage the process of procuring the asset and services needed to deliver and operate the asset. The current models commonly used in the market have been in place many years and even though they have matured over the years all fall into a common pattern whatever the model selected. To effectively procure data a new approach is required to operate at Level 2 with the existing contractual models.

Context of the Government’s Construction Strategy

The Construction Strategy contains thirteen distinct components designed to improve the effectiveness and influence of Government as a construction client and user of built assets. The BIM strategy is one of the thirteen policy strands but is important in that it brings together initiatives associated with better briefing and challenge, benchmarking, alignment of design and construction with operation and cost/carbon reduction.

As well as the direct alignment of BIM and Government Soft landings (GSL), indirect interfaces include the creation of benchmarking data, the alignment with procurement routes and the facilitation of challenge through the data drops process. This section briefly outlines how the BIM programme interfaces with these key Government Procurement initiatives.

Government Soft Landings (GSL)

GSL is now managed within the BIM task group. Its task is to ensure the needs of the assets user or operating base are involved in the design, delivery, commissioning and handover process in a way that facilitates a safe and secure handover.

Standard Procurement Routes

The Procurement Task team published its report in May 2012

(

www.gov.uk/government/organisations/cabinet-office/series/government-construction). In addition to the detailed definition of Government’s three preferred procurement options, the report describes Government’s role as an intelligent client, as well as proposals for the aggregation of government demand for generic

construction products and for government-driven initiatives to shape and improve the performance of the supply chain.

Alignment of Procurement Strategy and BIM

The three standard procurement routes are currently being piloted and as yet there has been no interface between a BIM pilot and a procurement pilot. In advance of this taking place, the BIM task team have undertaken a strategic assessment of the interfaces between procurement routes, BIM and BIM data drops. The alignment of cost-led procurement is examined in figure 5.

(12)

The “Plain Language Description”

1

Figure 5 – Outline process for cost-led procurement

Key features and benefits of cost-led procurement include:

ECI based on an integrated team

Team selected on collaborative competences

Output specification and cost target set ahead of team selection

Innovative design proposals developed by teams in selection

Opportunity let outside of the framework if the cost benchmark is not met

Cost reimbursable contract

Successful delivery creates opportunities for serial appointments

Our analysis sets out BIM value propositions that support the implementation of the chosen procurement route, additional EIRs specific to the procurement route and the additional outputs that use of the BIM model can provide. For example, under cost led procurement, use of BIM provides the following support to the procurement strategy

Value proposition – cost benchmarks, output based-specifications and de-risking of the agreement of not-to-exceed costs

EIRs – Required level of design completion. Level of performance to secure future opportunity within framework

Commercial processes supported by BIM - performance benchmarks, design submissions, gateway reviews

A similar analysis has been prepared for the Integrated Project Insurance and two-stage open book procurement routes. This analysis demonstrates that the approach adopted by the BIM strategy – involving the detailed specification of project

information outputs is fully aligned with strategic procurement initiatives.

Precedence of Contract Documents

This section explains how the family of commercial documents inter-relate and are applied on a specific project. The commercial process for the procurement of assets is managed through a set of documents that communicate the employer’s

requirements and the constructor’s response and which form the basis of the contract.

In addition to foreground documents such as the contract, appointment, employer’s requirements and schedules of service, there are supporting documents – some of which are project specific – such as the BIM execution plan, and some of which are

(13)

The “Plain Language Description”

1

general, such as PAS 1192:2:2013 and BS 1192 (2007). Industry standards such as

the Plan of Work also contribute to the basis of the agreement by helping to establish the standard by which a designer or constructor would be expected to undertake their services.

Figure 6 – Indicative contractual precedence diagram

The contract sets out the explicit terms on which an agreement is based, including consideration, timescales and required outputs. The contract governs all aspects of the work undertaken on behalf of the employer, whether based on BIM or not. Supporting documents including the Contractor’s Proposals, Schedules of Service and Project Outputs provide further details of the project specific activities to be

undertaken in connection with the contact. ERs and Schedules of Service tend to describe activities, processes or obligation. Increasing Contract Documents are focused on outputs and outcomes. The CIRs for example describe a series of outputs required at Project Stages in order to demonstrate that Project Outcomes will be met.

Outside of the Contract, Standards and Project Specific documents such as a PAS 1192:2:2013 compliant BIM Execution Plan (BEP) impose additional obligations or constraints. Under the BIM Strategy, a Protocol has been prepared to clarify the precedence of documents and to create obligations to apply these standards. All parties working on BIM projects need to have conventional appointment documentation in place. Presently, although RIBA have produced a BIM overlay of the Architect’s Plan of Work, only limited work has been undertaken on the drafting of BIM-specific extensions to schedules of service. CIC have commissioned a scope of service for an Information Manager which will help to inform the drafting of any changes to the current services necessary to describe changed project stages, outputs, information flows, roles and ways of working.

The BIM Protocol

A BIM Protocol has been prepared to introduce specific obligations and protections associated with the use of BIM models; this is published at www.bimtaskgroup.org in the commercial section. The Government Protocol is enforced by an amendment to the contract/appointment. Without the amendment, there is no specific BIM provision. The main provisions of the Protocol are as follows:

(14)

The “Plain Language Description”

1

Priority of the Contract Documents

Obligations of the Employer

▫ Put a Protocol in place

▫ Appoint to the role of Information Manager

Obligations of Project Team Members

▫ Produce the Specified Models

▫ Collaborative working practice

Electronic Data Exchange

▫ No warranty for data integrity

Use of models

▫ Licences related to permitted purposes

▫ Limitations related to the extension of a project

Limitations on liability associated with models The Protocol incorporates two key appendices

1. Levels of Detail and Model Production and Delivery Table

▫ Applies to the Specified Models only

▫ Formalises the Level of Detail required at a Data Drop/Project Stage

▫ Defines which party produces which Project Outputs at which data drop/project stages

▫ Can be amended and populated in line with procurement strategy 2. Information Plan

▫ Summarises and provides contractual affect to aspects of information management such as the definition of information management standards

The effect of the protocol and its appendices is to create individual obligations with respect to the model and the information plan without altering the basis of the appointment/contract/sub-contract. No additional obligations between parties are created through the use of BIM modelling and information exchange. All relationships between designers or between sub-contractors remain unchanged.

IP and Copyright under the BIM protocol

The Protocol addresses IP and copyright issues in connection with BIM models only. All rights, copyright, design right and model rights are dealt with by using a single set of licences. No distinction is drawn between these rights in the protocol.

The Protocol includes the following provisions:

Clarification on retained ownership of copyright;

Licences to the Employer to use Models for the permitted purposes, including the right to sub-licence;

Limitations on the employer’s right to sub-licence

Licences from the employer to project team members to use Models for the permitted purposes

Limitations on rights to modify models or to use on an extension of the project All other IP issues are dealt with through the governing contract

Practical issues associated with Levels of Detail

The Level of Detail and Model Production and Delivery Table (MPDT) is a critical document (see example in figure 7). Only models which are listed in the table are defined as being part of the BIM and hence subject to the provisions of the Protocol.

(15)

The “Plain Language Description”

1

It is expected that the MPDT will be populated by reference to the EIRs/CIRs –

specifically the schedule of models required at each data drop.

Figure 7 – Indicative completion of MPDT at initial appointment

In addition to defining the content of the BIM model, the Protocol establishes the party responsible for producing a model and the Level of Detail required at a particular stage. Adherence to the defined level of detail is very important contractually:

Designers undertake to produce information to a consistent level of detail which enables coordination and which provides assurance that risks associated with project definition have been mitigated

Recipients of information rely on information being produced up to a known level of definition. The working assumption of a recipient should be that any detail provided in excess of the required Level of Detail cannot be relied upon at that stage

Disciplined working in accordance with defined LoD embodies lean principles, improves design coordination and avoids the risk of duplicate or redundant definition work. Levels of detail are closely associated with the Project Stages defined by the Digital Plan of Work.

A key principle of the Digital Plan of Work is that a Project Stage cannot be completed until all definition work has been brought up to a common level of definition.

In practice, as different specialists may be involved in the definition of some elements of work, project procurement may dictate that some elements of definition are finalised at a later stage in the project. A widespread example is the appointment of Building Services on abridged duties – meaning that the detailed design of the services is completed long after the constraints of architecture and structure have been set. Many of the coordination and change control problems experienced on projects are associated with poorly coordinated design.

The BIM strategy is based on the production of data drops at the end of Project Stages. An underlying assumption of the strategy, further emphasised by the Digital Plan of Work is that all materially significant definition work will be completed to a common level of detail prior to Stage Sign Off.

In practice some data drops may take place before the end of a stage – associated with Early Contractor Engagement for example.

If this practice is adopted, then the following best practice principles should be adopted.

Agreement to a reduced LoD is only acceptable where there is no material risk of poor coordination or redesign. E.g.; plant room design will be based on an initial assessment of the size of key elements of plant and distribution;

Activities necessary to provide assurance in connection with coordination must be completed – e.g. definition of services coordination zones;

The actual level of detail achieved must be recorded and communicated. Information providers must comply with the LoD that they have signed-up to.

Stage definitions: eg: APM

LoD definitions eg: PAS 1192

High Level

Level of Detail Drop 1 Drop 2a Drop 2b Drop 3 Drop 4

Stage 1 Stage 2 Stage 2 Stage 3 Stage 6

LOD definitions (from PAS 1192) Stage definitions (from APM)

Architectural 1 2 3 4 6

Structural 1 2 3 4 6 1 Brief 0 Strategy

Services 1 1 3 4 6 2 Concept 1 Brief

3 Developed Design 2 Concept

Originator Drop 1 Drop 2a Drop 2b Drop 3 Drop 4 4 Production 3 Definition

Stage 1 Stage 2 Stage 2 Stage 3 Stage 6 5 Installation 4 Design

6 As constructed 5 Build & Commission

Architectural Arch Arch Arch Con Con 7 In use 6 Handover & Closeout

Structural Eng Eng Eng Con Con 7 Operation and end of life

(16)

The “Plain Language Description”

1

Levels of detail within a package (e.g. structural steel connections, architectural metalwork, BMS system design) should be consistent, even though there may be some variation across outputs of a discipline.

Work should be completed to a consistent LoD for all elements that have a cost, time, aesthetic or working-method impact.

Role of the Employers Information Requirements EIRs/CIRs,

including definitions of Project Outputs

The EIRs/CIRs have a critical role in defining project outputs and in establishing the standard ways of working that will be enforced through obligations created by the Information Plan.

The content of the EIRs/CIRs are shown in figure 8.

Technical

Management

Commercial

Software platforms Alignment of data drops with HA project control stages Model list aligned with protect control stages

Coordinate definitions Level of detail definitions Definitions of strategic purposes of information Training

Standards

Roles and responsibilities Work planning, design management and data segregation

Security issues Coordination and clash detection process Model sharing process Model review meetings H&S and CDM(M)

Defined BIM deliverables for CPs

BIM capability and experience Evidence of BIM execution planning

Confirmation of BIM toolset Details of BIM workload and resourcing

1. Organisation

2. Principal supply

chain

BIM assessment criteria with agreed scoring

Figure 8 – Outline content of the EIRs

Figure 8 is an indicative example only and may need to be updated with reference to latest version of the CIRs

The detailed definition of the BIM models required for each Data Drop will be used to populate the MPDT – effectively defining the scope of the BIM Model for the purposes of the contract. Standard ways of working described in the EIRs/CIRs, such as the operation of the Common Data Environment described in PAS 1192:2 are enforced as a Contract Obligation if they are included in the Information Plan.

(17)

The “Plain Language Description”

1

Figure 9 – Typical data drop requirement in EIR

Figure 9 shows how the EIRs act as a comprehensive reference describing Project Outputs at each data drop. In the case of the BIM Model, the scope of the Model needs to be incorporated into the Protocol – potentially by direct reference to the EIRs

The employer and the employer’s advisors will benefit from a good

understanding of the commercial documents associated with the BIM process, because the team has created the opportunity to clearly define and enforce requirements.

Comprehensive completion of the EIR/CIR document, together with the regular review and updating of the Levels of Detail and Model Production and Delivery Table will help to ensure that necessary clarity is in place to enable separate appointments and contracts to be effectively coordinated.

Stage 4: tender requirements Heading Description B IM m o d e l* 2 D P D F d ra w in g s 2 D D W G d ra w in g s C O B ie -U K -2 0 1 2 D o c u m e n ta ti o n W h o ?

Overall form and content

Space planning Overall zoning. Approximate scale of spaces and of the building as a whole. Required adjacencies and circulation pattern

Client’s design team Site and context Relationship to adjacent buildings and

external uses/circulation. Target levels.

Client’s design team External form and

appearance Example approach Client’s design team Design strategies

Fire Implicit in model. Requirements stated in

documentation. Client’s design team Physical security Implicit in model. Requirements stated in

documentation.

Client’s design team Disabled access Implicit in model. Requirements stated in

documentation. Client’s design team Maintenance access Implicit in model. Requirements stated in

documentation. Client’s design team BREEAM Requirements stated in documentation.

See BREEAM Contractor Performance

Specification

Client’s design team Performance

Building Requirements stated in documentation.

Client’s design team MEP systems Requirements stated in documentation.

Client’s design team Elements, materials components

Building Requirements stated in documentation.

Client’s design team MEP systems Requirements stated in documentation.

Client’s design team Health and Safety

Pre-construction information (PCI)

document Client’s design

team Outline risk assessments from

design team members (included in PCI) Client’s design team

(18)

The “Plain Language Description”

1

Digital Plan of Works

The Digital Plan of Works (dPoW) is the articulation of the project delivery stages and the level of detail/definition that needs to be delivered by each supplier/discipline to the employer at any point in time. As we have described the documentation of these definitions are complex and become even more complex once data is defined at BIM level 2 working. This section is designed to outline each of the elements and how they are brought together to form the dPoW in a coherent usable manner for institutions, suppliers and clients. There are three axis of competing definition we need to navigate (Plan of Work Stages, Level of Definition/Detail and user or audience), to enable these to be navigated simply we have placed them on the axis of a cube. This is illustrated in figure 10.

The purpose of using the cube is to allow us to navigate the various data sets and definitions as quickly and as simply as possible to enable users to concentrate on delivering projects rather than worrying about interpreting definitions and finding documents. It is our expectation that this will be further simplified by the fact that the cube will be presented in an electronic web portal.

(19)

The “Plain Language Description”

1

The Plan of Works

The plan of works we have defined here is based on the latest CIC documentation. These documents provide a generic framework to enable institutions to overlay local knowledge, taxonomies and brands, whilst preserving consistency in the new underlying data definitions and minimum levels to allow transparent coordination across disciplines in multi discipline projects and schemes. Indeed this process has already commenced with both RIBA and CIBSE already contributing and publishing documentation in this area.

Project Hierarchy or Data Types

The process of developing a BIM model creates many types of information. This information is categorised into a hierarchy of information to enable it to be managed and used by appropriate parties, this hierarchy is the backbone of the BIM approach.

The most common types of data or content are

Materials

Objects (Components)

Assemblies

Projects

Materials

Materials are the baseline from which all geometry and data is derived. They carry all of the base information of the material including composition,

performance, appearance and cost. Examples include; timber, steel, glass and

concrete and each has their own specific properties. Materials that carry this information can be analyses and selected on their specific merits. However special care must be made when assemblies are made up of multiple materials each with performance criteria unrelated to the assembly as a whole.

This relationship is described in figure 11.

Figure 11 – Interrelationship of project data and other data types

Objects (Components)

BIM Objects or components elemental parts of a project that work inside a BIM model and are characterised by being able to stand alone, they don’t need to

(20)

The “Plain Language Description”

1

rely on any other objects to be understood. They carry information about their

identity, appearance, performance and usage. This information set should be complete enough to enable a designer to locate, specify and analyse the object. Additional information relating to the materials contained in the object may be added. For example a window may have handling or operation information included as well as glass type, colour, grid, weather protection or ironmongery. Certain objects have behavioural information included, this enables them to only be placed in certain locations or orientations into the model, for example the window object into a wall. This prevents inadvertent placing of information making the design process quicker to deliver and check.

Assemblies

BIM Assemblies are made up of any number of materials and objects to provide an easy to use set of useful parts. This may be in the form of a room, bridge or gantry type asset. They are particularly relevant where an asset is repeated many times on a project. It should be remembered that if an assembly is modified to meet the specifics of a project it will become a new assembly. This process is demonstrated in the example below.

It should be noted that data held at material level can be “inherited” through the hierarchy to components, assemblies and projects.

Project

A BIM Project is the collection of all the generic assemblies and components used in the actual project. The data and geometry are developed using the BS1192/2/3 processes. This development process ensures that federated

models (necessary through the limitations of level 2 BIM) are brought together into a defined project dataset for submission the Employer to execute the contract and the deliver the physical asset.

Example of Project Hierarchy or Data Types

Materials and objects (components) carry their own information which not only helps define the assembly but also allows them to be created once and used many times. In the example below we show how a simple scenario of a cheese sandwich can have many combinations.

(21)

The “Plain Language Description”

1

Project Lunch Assembly Cover Filling Lubricant Materials Bread Brown White Wholemeal French Flat Soda Cheese Hard Cheddar Parmesan Soft Brie Camembert Lubricant Butter Margarine

In the example shown we have 48 combinations, but if the sandwich became open faced or the cheese were on the top rather than the bottom it becomes a combination of 96. Clearly an effective management system is needed to cope with these new scenarios. In wider applications it is worthy of note that the same principles are used in automotive manufacturing and an asset such as a BMW 3-series car has up to 3 Million combinations.

(22)

The “Plain Language Description”

1

How does the Data Hierarchy Relate to the dPoW?

Figure 12 describes the relationship between the delivery stages (Plan of Work), geometry and data maturity and the data type hierarchy. The horizontal red line depicts the transactions needed to develop the BIM model through the

production process described by PAS1192:2:2013. It should be noted that the red line is of particular significance as the data sets above the line once processed by the various BIM tools become project specific and so the data derived from the generic assemblies or objects (components) may have now changed.

The figure indicates the maturing geometry and data sets and how the “Plain Language Questions” (Q) are directly linked to the data sets required.

The generic details of these definitions are described in the tables below, the “z” axis of our cube described above caters for the various players in the process and separate schedules exist for each community.

Figure 12 – dPoW and data maturity

The Level of Detail schedules contained in the following pages (20-23) are taken from the CIC document suite. However as can be seen there are no provisions for describing the various data requirements documented above. These data management definitions are described in the following section.

(23)

The “Plain Language Description”

1

Level of Detail Development for presenting the information relating to a project (Please Note : These will be consolidated with the PAS/CIC and feedback tables) Model Name : Generic 1 Brief 2 Concept 3 Definition 4 Design 5

Build & Commission 6

Handover & Closeout 7

Operation & End of Life

System(s) to be covered

N/A All All All All All All

Graphical illustration

Certainty / Purpose

Project brief and procurement strategy

Refined project brief and concept approval. Design contingency of 20-25% Approval of coordinated developed design. Design contingency of 10-15% Integrated production information. Complete fabrication and manufacturing details, systems and element verification, including commissioning, operation and maintenance information Design contingency of 5-10%

Construction progress and integrated production information updated as appropriate Commissioning and performance data As constructed systems, operation and maintenance information. Building Log Book. Information gathered as key elements are completed to feed installation information for the later packages.

Agreed final account in use performance compared against Project Brief Project process feedback:

Risk, procurement, information, management, soft landings.

(24)

The “Plain Language Description

1

Attributes / Data Project needs

updated: definition of function(s), operation, quality and time. Benchmarking updated: capital cost, maintenance cost, time,

health & safety, risk procurement contract Performance requirements: priorities and aspirations for: Function, mix of uses, scale, location, quality, performance in use,

Cost (Capex & Opex), value, time, health & safety, embodied and in use carbon, energy and resource needs, standard designs. Site constraints: geo spatial, available site information.

Sufficient data to estimate per square meter rates and other similar metrics. Wireframe or surfaces / solids

Concepts, site context Placeholder / volumes / package zones System routings, Site selection, datum points & levels Integrated concept for the project setting scope, scale, form and primary design criteria: architectural form and spatial arrangements, structural / civil philosophy and spatial arrangements, services philosophy and special arrangements preliminary assessment of energy use and embodied / in use carbon, Incorporation of

Co-ordinated Developed Design for the project setting: generic systems, objects, or assemblies represented with, detailed form, function, cost, defining all components in terms of overall size, typical detail, performance and outline specification, primary geometry frozen, integration of standard designs and systems,

builder’s work strategy for significant interfaces, energy use,

Embodied and in use carbon.

Maintenance plan Detailed design and construction programme

Production Information for the project: Specific systems, objects and assemblies accurate in terms of specification, size, form, function and location. Critical interfaces flagged.

Fixing methodology. Confirmed clash free. Detailed production programme sequence. Updated: energy use and embodied and in use carbon, detailed design and construction programme,

Production record for the project:

Specific systems, objects and assemblies accurate in terms of specification, size, form, function and location with detailing, fabrication, assembly, and installation information.

Detailed routing of systems. Fixings and interfaces details to be used. Updated: energy use and embodied and in use carbon, detailed design and construction programme,

Updated:

Geometry and installed product information, “as constructed”

Accuracy / resolution of information.

Commissioned performance for: Opex, energy, and carbon. Detailed maintenance methodology.

Snagging actions status.

Revisions for modifications to the facility during its life.

(25)

The “Plain Language Description

1

Operation & End of Life standard systems. Critical interfaces and logic (examples): NA Environmental control

philosophy and special allocations for ventilation;

Availability of the site and outline construction methodology

assumptions; Services capacity for the site;

Permitted working hours on site.

Assumed procurement package performance and spatial boundaries; Other relationships between procurement packages;

Assumed design codes regarding dimensional tolerances of related systems;

Foundation tolerances for use of off-site modular systems. Assessment of predicted movements (thermal, loading, creep, shrinkage etc). Allocated procurement package relationships, performance and special boundaries; Actual dimensional interface requirements; Records of any derogations approved; Actual on-site to off-site interface specifications.

Progressive capture of actual dimensional data for critical interface

dimensions.

Progressive capture of information for calculating material requirements for follow on packages. Capture of object status for progress reporting and collaborative planning.

As constructed 3D scan. Element performance test results.

System commissioning status.

As modified survey data

Construction requirements (examples)

N/A Crane use zones;

Traffic diversions.

Confirmed crane (or other lifting system) zones.

Formwork details. Traffic diversion details

Actual crane (or other lifting system) zones and movement sequences. Construction

methodology, sequence and movements, critical to how the production design is developed.

Status of construction requirements.

Safety briefing information. Construction methodology, sequence and movements, critical to installation. Formwork details including install and removal sequence.

Actual traffic diversion

Confirmed status that the construction aids have been removed.

(26)

The “Plain Language Description

1

Operation & End of Life details. Project logistics and off-site activities (examples) Client requirements, EG to avoid impact on other operations

Assumed access and egress points; Potential delivery and lay down zones.

A feasible logistics sequence for the construction sequence; Confirmed modular strategy (volumetric, panelised, hybrid or other). Finalised logistics sequences.

Details of actual off-site system to be used.

Object status progress recording to initiate demand pull signals for deliveries.

Remote monitoring systems status Remote monitoring systems status Project facilities (welfare, IT infrastructure, security etc), on-site and off-on-site (examples):

Collaboration tools; Data standards.

Assumed access and welfare zones; Design team colocation.

Confirmed access zones and design team colocation.

Finalised, costed plan. Critical lead times confirmed.

Off-site manufacturing capacity reserved.

Recording status of security critical areas (EG

unchecked, sweep in progress, screened and secured)

Security system operational, potentially using model information for lines of sight from cameras, PAVA zone controls etc.

Security system operational.

Facilities management systems running on model generated information. Geometry for letting activities accessed from “as constructed” model. Notes and associated project documents, based on model information: Management systems for information and decision making Approval policies Technical strategy studies Commissioning philosophy

NRM1 capital cost plan NRM3 maintenance cost plan.

Provides the basis for Integrated Production Information to be produced on a package basis with limited risk of changes to primary coordination. Room Information sheets, Detailed construction methodology NRM2 and Updated: maintenance plan, risk management plan, detailed construction methodology, NRM2 procurement pricing schedule, NRM3 maintenance cost plan,

health and safety risk management plan,

Detailed construction methodology,

Updated health and safety risk management plan NRM3 maintenance cost plan,

Approximate final account Maintenance procurement pricing

Remedial works, handover and maintenance programme

N/A

(27)

The “Plain Language Description

1

NRM3 cost plans Health and safety risk management

Risk management plan.

(28)

The “Plain Language Description

1

Defining Digital levels of Details

Using the traditional scope tables shown above we have defined the following template datasets for a series of well used asset elements (currently 12 but extending to around 2500). These datasets are described in a spread sheet (separated one for each element) to enable both users and manufacturers to clearly see what data attributes are needed at each stage. Examples of these sheets are available in the Labs area of www.bimtaskgroup.org.

From these spread sheets we can discover:

What I need

What I have been delivered

How do I find the difference

How does this help

What is there left to do?

Figure 13 – Data Requirements Schedule (Demand Matrix)

Checking Data

With the availability of COBie data from the BIM Models and the demand matrices documenting the digital Plan of Works requirements it is now a relatively easy task to compare the two and validate the COBie data.

(29)

The “Plain Language Description

1

Figure 14 – Data Transfer & Validation Process

Figure 14 shows how this process will operate. Data is developed by the supply chain using PAS1192:2:2013 as can be seen through the Common Data Environment at the top of the page. This data set as defined by the EIRs is passed through the issue process (green football in the diagram) into some type of data management service. The native files, 2DPDFs and COBie files are stored in a Repository. The COBie file is then validated by comparing the COBie data with the demand matrix (PoW - LoD). Figure 15 details this process, with the results being presented in a new COBie spread sheet which is coloured in red, amber and green, depending upon data validation criteria described below. Once all the cells have turned green the COBie data is ready for further use, indicating the ability to answer the Client Questions, cost

planning and other high value uses. It will be further possible to use Uniclass (2) to further sort the COBie data to enable it to be used by other audiences or users.

(30)

The “Plain Language Description

1

Figure 15 –Validation Details

To enable a better understanding of this validation process we have provided some example models and validation/demand matrices, together with a small computer application which allows the validation of the COBie data files. The validation checks for:

o Compliance o Continuity o Completeness.

A full user guide for the application is contained in this document. Please note this application is provided for educational and comment purposes only and it is our expectation that the software vendor community will respond with production

or embedded versions of this capability. If you do try the application please feedback your experience to the comments section of the BIM Task Group website.

(31)

The “Plain Language Description

1

Managing Specification Information

The Management of Specifications is a perennial challenge, add too much detail and you add cost without value, include too little and your asset may not work. Specifications seem to grow with time. Most organisations are happy to add but all seem loathed to remove/

The effective management of briefing and specification is only equalled in importance with a clear understanding of the client or operator needs of the asset. BIM can and will re-focus our attention onto this key area as it represents a clear areas of potential benefit.

The ability to integrate Specification data into the BIM data scenario is now being better understood as are the latent benefits in such an approach. As we have discovered in earlier sections, it is now possible to validate the quality of our delivered data from the supply base. We have also seen how this validated data can be used to answer the Plain Language questions, but a clear extension to this process is to test against the specification.

The following section shows how the NBS have taken our cheese sandwich example and have applied a sample specification by way of example.

(32)

The “Plain Language Description

1

Example of Specification Application

Figure 16 – NBS Create Example

The process commences with a brief feeding into the process. In this case it is for a sandwich as outlined in the assembly example above.

Figure 17 – NBS Create Example

The user would need suggested values to help them link with potential “products” or materials to the assembly. As shown below the user has decided they want to have nice and healthy wholemeal bread. This is given definition as we know that this is to be the bread to the layer of the base. Also note below a structure within the sandwich definition to give it real meaning – not just a flat property set.

(33)

The “Plain Language Description

1

Figure 18 –Filling Details

Of course the user may not want a cheese sandwich. They may want tuna… and some sweet corn too. The screenshot below shows cheese, ham and tomato being added. Three materials for the base filling.

Figure 19

The specifier may want to leave this as an outline description of the sandwich. This is shown in figure 19. However, they want to make visible the

products/materials they have selected. This will be the next level down – the materials – this is shown in the screenshot two down.

(34)

The “Plain Language Description

1

Figure 20 – Select Bread Type

All of the materials haven’t been modelled. But the butter and the bread are shown in figure 20. Again, suggested values are offered so you can tailor the exact type of bread you want.

Figure 21 – Workmanship Details

And of course putting a sandwich together is a skill. Too much butter and you can ruin it. So we also want to specify the workmanship. We want the perfect sandwich. Notice the relationship between the butter material and the butter workmanship clause.

Once the Specification process is complete it can then be attached to the assembly.

(35)

Technical Definitions & Specifications

2

PART 2 – Technical Definitions &

Specifications

Grouping of Component Occurrences

COBie, IFC and all BIM authoring tools allow the user to manage Component occurrences. There may be a need to manage named groups of these Component occurrences.

Systems

COBie, IFC and most BIM authoring tools offer the capability to group Component occurrences into functional Systems. However, there are various methods used:

Assigning a System name to an Attribute of a Component

▫ Component “Light Fitting LF 001” has property “Circuit” set as ”Ground Floor Lighting”

Assigning the Component to a previously defined Layer named to reflect the System

▫ Layer ”Ground Floor Lighting” contains Component “Light Fitting LF 001”

Assigning a Component to previously defined System

▫ System ”Ground Floor Lighting” includes Component “Light Fitting LF 001”

Using Components whose assignment to a System is unambiguous

▫ For example IfcLightFitting may implicitly imply “Lighting Installation”

Note that COBie and IFC allow Systems to be nested.

Assemblies

However there are cases where it is desirable to document and exchange Assemblies, where the group may not be defined by any specific function. Such groups may represent a current project proposal or a recommended or prior design library solution:

For the contents of a space

For a wall or slab construction

For a prefabricated pod

A number of approaches are possible

Treat the Assembly as a System (classified at a high level such as RICS NRM “6 Prefabricated Buildings and Building Units”

Treat the Assembly as a Component, but loose the composition information

Exploit other available tools in the BIM authoring and FM management tools.

(36)

Technical Definitions & Specifications

2

The Issues

Treatment of Assemblies and Attributes

When an Type is created as a single item it is a relatively straightforward to assign Attributes to that element, as it has no reference to any other item and is not yet specific to the project that it is being delivered to so there are no dependencies. If you start to group objects you create a group of objects or “Assembly”. Assemblies of Components or Types may then require Attributes themselves. This can then create dependencies and relationships which are complex and sometimes unexpected. The standard data structures such as COBie and IFC both cope with this scenario but the methods used by each BIM software vendor to create such Assemblies varies again promoting unexpected outcomes. By way of example one key area where this may be significant is in the specification of maintenance information which may be different for the same object in different assembly scenarios.

Legal Concerns

There may also be issues around the commercial and legal use of objects, assemblies and project data, especially if derived from proprietary data sets or manufacturers. A detailed specification of use and applicability is needed to allow clear guidance to be passed to the legal community to evaluate the impacts on current and emerging standards and contracts.

Exchange of Assemblies

There may be a number of routes and options available for saving and re-using Assemblies. BIM authoring tools may represent assemblies but exports may need to be checked to ensure all information is preserved.

Saving to IFC - Are Assemblies documented correctly with all positioning and attributes?

Reporting tools: Can both the owning object and the owned objects be scheduled and can the ownership be reported?

COBie specific adapters: Can any COBie export mechanism report both the owning and owned objects? Are the attributes of both included?

Saving to proprietary format(s). Can the Assembly be saved to a proprietary format for re-use, separate from the project?

BIM authoring tools and FM applications may represent assemblies adequately but imports should be checked to ensure sufficient information is preserved:

Reading IFC - Are the owning and owned objects read, along with location and attributes?

Reading proprietary formats. Can the Assembly be loaded from a proprietary format for re-use, separate from the project?

(37)

Technical Definitions & Specifications

2

Example

A “Classroom Assembly” has been prepared to support the Challenge. Respondents are invited to use this model to show the capabilities of their applications, and to provide back other examples in IFC and COBie formats.

Figure 22: The Assembly consists of 16 desks, 33 chairs and a whiteboard

Figure 23: The Assembly is located within a space with walls, a slab and a door

Figure 24: The owning “ClassRoomLayout1” and the owned furniture have representations

(38)

Technical Definitions & Specifications

2

Figure 26 - Each owned item of furniture has a number of property sets associated

COBie Representations of Assemblies

COBie has an ‘Assembly’ tab. Every Assembly relationship has

A name,

The name of the owning object

The name of the owned object

It can join owned Components together to make an owning Component.

Both the owner and owned objects have entries in the Component table.

Each row in the Assembly table adds one owned Component to the owning Component.

The owning Component, the owned Components and/or the Assembly row can have document, attributes and impacts associated.

N am e C re at ed B y C re at ed O n A ss em bl yT yp e S he et N am e P ar en tN am e C hi ld N am es E xt S ys te m E xt O bj ec t E xt Id en tif ie r D es cr ip tio n Stair: Commercial - Ext Steel Fire escape:213759 assembly 01 F ix ed C om po ne nt Stair: Commercial - Ext Steel Fire escape:213 759 Stair: Commercial - Ext Steel Fire escape:213 759 Ifc S ta ir Stair: Commercial - Ext Steel Fire escape:213 759 Stair: Commercial - Ext Steel Fire escape:213759 assembly 02 F ix ed C om po ne nt Stair: Commercial - Ext Steel Fire escape:213 759 Railing:1100 mm:213832 Ifc R ai lin g Railing:1100 mm:213832 Stair: Commercial - Ext Steel Fire escape:213759 assembly 03 F ix ed C om po ne nt Stair: Commercial - Ext Steel Fire escape:213 759 Railing:1100 mm:213836 Ifc R ai lin g Railing:1100 mm:213836

Table 1: COBie Assembly (Components)

Component Assemblies can be qualified with Coordinate information. Components can be given Point locations with orientations.

(39)

Technical Definitions & Specifications

2

N am e C re at ed B y C re at ed O n C at eg or y S he et N am e R ow N am e C oo rd in at eX A xi s C oo rd in at eY A xi s C oo rd in at eZ A xi s

Stair:Commercial - Ext Steel Fire

escape:213759 assembly 01 point point Assembly

escape:213759 assembly 01 -450 0 0 Stair:Commercial - Ext Steel Fire

escape:213759 assembly 02 450 260 0 Stair:Commercial - Ext Steel Fire

escape:213759 assembly 03 0 0 0

Table 2: COBie Coordinate (Component Assembly)

It can join owned Types together to make an owning Type.

Both the owner and owned objects have entries in the Type table.

Each row in the Assembly table adds one owned Type to the owner Type.

(40)

Technical Definitions & Specifications

2

N am e C re at ed B y C re at ed O n A ss em bl yT yp e S he et N am e P ar en tN am e C hi ld N am es E xt S ys te m E xt O bj ec t E xt Id en tif ie r D es cr ip tio n

Basic Roof:Flat - Warm

Concrete layer 01 Layer Type

Basic Roof:Flat -

Warm Concrete Roofing - Felt IfcMaterialLayer Roofing - Felt : 4. Basic Roof:Flat - Warm

Basic Roof:Flat - Warm Concrete

Insulation / Thermal Barriers -

Rigid insulation IfcMaterialLayer

Insulation / Thermal Barriers - Rigid insulation : 150. Basic Roof:Flat - Warm

Basic Roof:Flat -

Warm Concrete Concrete - Sand/Cement Screed IfcMaterialLayer

Concrete - Sand/Cement Screed : 50.

Basic Roof:Flat - Warm

Basic Roof:Flat -

Warm Concrete Concrete - Cast In Situ IfcMaterialLayer Concrete - Cast In Situ : 150. Basic Roof:Flat - Warm

Basic Roof:Flat -

Building Information Modelling