Building Information Modelling

Transcription

1 Building Information Modelling The Digital Plan of Work & Assemblies 5 March 203 DRAFT ONLY V7-

2 Version Control Version Various Authors for comment Version 7 28/2/3 Issue for Comment and Information on Version 7-5/3/2 Revised to coordinate CIC, PAS92:2:203 Stages

3 Contents 0 PART The Plain Language Description... Participants in the Preparation of this Document... 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... 0 IP and Copyright under the BIM protocol... Practical issues associated with Levels of Detail... Role of the Employers Information Requirements EIRs/CIRs, including definitions of Project Outputs... 3 Production of Commercial Data... Error! Bookmark not defined. Digital Plan of Works... 5 The Plan of Works... 6 Project Hierarchy or Data Types... 6 Materials... 6 Objects (Components)... 6 Assemblies... 7 Project... 7 Example of Project Hierarchy or Data Types... 7 How does the Data Hierarchy Relate to the dpow?... 8 Defining Digital levels of Details Checking Data Managing Specification Information Example of Specification Application PART 2 Technical Definitions & Specifications Grouping of Component Occurrences Systems Assemblies The Issues COBie Representations of Assemblies IFC representations of assemblies Checking For Compliance Introduction Compliance, Continuity and Completeness Compliance Completeness Demand Matrix Supplementary Demand Matrix Glossary... Error! Bookmark not defined. References... Error! Bookmark not defined. BIM The Digital Plan of Work

4 The Plain Language Description PART 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 MR 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 BIM The Digital Plan of Work Page

5 The Plain Language Description 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 206 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. construction data. It is our intention to shape the future production digital Plan of Works through this process. Standards Guides Classifications Delivery Level 0 Level Level 2 Level 3 CAD 2D 3D AIM SIM FIM BSIM BIMs CPIC AVANTI BS 92:2007 User Guides CPIC, Avanti, BSI BRIM IDM IFC ISO BIM ibim Drawings, lines arcs text. etc Models, objects, collaboration Integrated, Interoperable Data BS 92:2007 BS 7000 : 4 Building Information Management : inc Guide to BS92 CPIC Uniclass/CAWS BS92 :2 CAPEX BS 854:2 BS 854::3:4 BS92:3 OPEX IFD 2008/0 Bew - Richards Guide Guide 2 Guide 3 CPIC RIBA/ACE/BSRIA Plan of work Includes contractual and level of detail Figure A BSi (555) Roadmap) IFC IDM IFD Lifecycle Management New classifications to assist lifecycle delivery Increase level of detail and content as lifecycle knowledge grows 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 BIM The Digital Plan of Work Page 2

6 The Plain Language Description 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 conspired against our ability to manage for some years but well thought through Standards such as BS92 and its BIM Level 2 brother PAS 92:2:203 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 PAS92:2:203 and Figure, reproduced from the same document indicates this cycle. 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. STRATEGY DELIVERY Master Information Delivery Plan (MIDP) EXECUTION CONTRACT AWARD BIM Execution Plan (BEP) Project Information Model (PIM) PROCUREMENT Asset Information Model (AIM) Documentation NEED Employer s Information Requirements (EIR) Capex Start This document seeks to explain how this new digital data is procured at Level 2 (REF to enable clear definitions of need to the supply chain and use full data detailed to the client for use. Non-Graphical Data Graphical Model BRIEF CONCEPT DEFINITION DESIGN BUILD & COMMISION HANDOVER & CLOSEOUT OPERATION IN USE COMMON DATA ENVIRONMENT (CDE) Opex Start MAINTENANCE and USE (PAS92-3) SUPPLIER S INFORMATION EXCHANGE n EMPLOYER S DECISION POINT For details on supplier s information exchanges and employer s decision points see CIC Scope of Services Legend Green Information Process Blue Management Process Figure - The information delivery cycle (PAS92:2:203) BIM The Digital Plan of Work Page 3

7 The Plain Language Description 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. 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. 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 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 202 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. BIM The Digital Plan of Work Page 4

8 The Plain Language Description 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. Brief 2. Concept. 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. Project Stage 3. Definition Capital Delivery Phase Operations & Maintain Delivery Phase 4. Design 5. Build & Commission 6. Handover & Close Out Operational Decisions N N N 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. Data & Geometry Maturity 0% 00% 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 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 BIM The Digital Plan of Work Page 5

9 The Plain Language Description 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. 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. 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 subdivided. 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 Figure 4 - An evolution of models and content development for a facility BIM The Digital Plan of Work Page 6

10 The Plain Language Description 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 Plant rooms BIM The Digital Plan of Work Page 7

11 The Plain Language Description 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 202 ( 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. BIM The Digital Plan of Work Page 8

12 The Plain Language Description 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 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 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 twostage 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 BIM The Digital Plan of Work Page 9

13 The Plain Language Description general, such as PAS 92:2:203 and BS 92 (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. 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 92:2:203 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 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. A BIM Protocol has been prepared to introduce specific obligations and protections associated with the use of BIM models; this is published at 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: Supporting documents including the Contractor s Proposals, Schedules of Service and Project Outputs provide further details of the project specific activities to be Definitions BIM The Digital Plan of Work Page 0

14 The Plain Language Description 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. 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. BIM The Digital Plan of Work Page

15 The Plain Language Description 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. Stage definitions: eg: APM LoD definitions eg: PAS 92 High Level Level of Detail Drop Drop 2a Drop 2b Drop 3 Drop 4 Stage Stage 2 Stage 2 Stage 3 Stage 6 LOD definitions (from PAS 92) Stage definitions (from APM) Architectural Structural Brief 0 Strategy Services Concept Brief 3 Developed Design 2 Concept Originator Drop Drop 2a Drop 2b Drop 3 Drop 4 4 Production 3 Definition Stage 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 Services Eng Eng Con Con Con 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. BIM The Digital Plan of Work Page 2

16 The Plain Language Description 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. 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 92:2 are enforced as a Contract Obligation if they are included in 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. Organisation 2. Principal supply chain BIM assessment criteria with agreed scoring Figure 8 Outline content of the EIRs BIM The Digital Plan of Work Page 3

17 The Plain Language Description Stage 4: tender requirements Heading Overall form and content Space planning Site and context External form and appearance Design strategies Fire Physical security Disabled access Maintenance access BREEAM Performance Building MEP systems Elements, materials components Building MEP systems Health and Safety Description Overall zoning. Approximate scale of spaces and of the building as a whole. Required adjacencies and circulation pattern Relationship to adjacent buildings and external uses/circulation. Target levels. Example approach BIM model* 2D PDF drawings 2D DWG drawings COBie-UK-202 Implicit in model. Requirements stated in documentation. Implicit in model. Requirements stated in documentation. Implicit in model. Requirements stated in documentation. Implicit in model. Requirements stated in documentation. Requirements stated in documentation. See BREEAM Contractor Performance Specification Requirements stated in documentation. Requirements stated in documentation. Requirements stated in documentation. Requirements stated in documentation. Documentation Pre-construction information (PCI) document Outline risk assessments from design team members (included in PCI) Who? Client s design team Client s design team Client s design team Client s design team Client s design team Client s design team Client s design team Client s design team Client s design team Client s design team Client s design team Client s design team Client s design team Client s design team 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. Figure 9 Typical data drop requirement in EIR BIM The Digital Plan of Work Page 4

18 The Plain Language Description 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 0. 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. Figure 0 The Digital Plan of Works BIM The Digital Plan of Work Page 5

19 The Plain Language Description 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. 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. 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 Figure Interrelationship of project data and other data types 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 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 BIM The Digital Plan of Work Page 6

20 The Plain Language Description 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. 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. 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 BS92/2/3 processes. This development process ensures that federated BIM The Digital Plan of Work Page 7

21 The Plain Language Description 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. BIM The Digital Plan of Work Page 8

22 The Plain Language Description How does the Data Hierarchy Relate to the dpow? Figure 2 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 PAS92:2:203. 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 2 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. BIM The Digital Plan of Work Page 9

23 The Plain Language Description 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 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 0-5% Integrated production information. Complete fabrication and manufacturing details, systems and element verification, including commissioning, operation and maintenance information 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. Design contingency of 5-0% BIM The Digital Plan of Work Page 20

24 The Plain Language Description 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 Brief 2 Concept 3 Definition 4 Design 5 Build & Commission 6 Handover & Closeout 7 Operation & End of Life 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. BIM The Digital Plan of Work Page 2

25 The Plain Language Description 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 Brief 2 Concept 3 Definition 4 Design 5 Build & Commission 6 Handover & Closeout 7 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. 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 Assessment of predicted movements (thermal, loading, creep, shrinkage etc). 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. Confirmed status that the construction aids have been removed. Confirmed status that the construction aids have been removed. Actual traffic diversion BIM The Digital Plan of Work Page 22

26 The Plain Language Description 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 Brief 2 Concept 3 Definition 4 Design 5 Build & Commission 6 Handover & Closeout 7 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), onsite and off-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 NRM 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 (project closed) BIM The Digital Plan of Work Page 23

27 The Plain Language Description 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 Brief 2 Concept 3 Definition 4 Design 5 Build & Commission 6 Handover & Closeout 7 Operation & End of Life NRM3 cost plans Health and safety risk management risk management plan. Risk management plan. BIM The Digital Plan of Work Page 24

28 The Plain Language Description 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 2 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 From these spread sheets we can discover: Figure 3 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. What I need What I have been delivered How do I find the difference How does this help What is there left to do? BIM The Digital Plan of Work Page 25

29 The Plain Language Description Figure 4 shows how this process will operate. Data is developed by the supply chain using PAS92:2:203 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 5 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. Figure 4 Data Transfer & Validation Process BIM The Digital Plan of Work Page 26

30 The Plain Language Description 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. Figure 5 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 BIM The Digital Plan of Work Page 27

31 The Plain Language Description 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. BIM The Digital Plan of Work Page 28

32 The Plain Language Description Example of Specification Application Figure 7 NBS Create Example Figure 6 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. 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. BIM The Digital Plan of Work Page 29

33 The Plain Language Description Figure 9 The specifier may want to leave this as an outline description of the sandwich. This is shown in figure 9. 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. Figure 8 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. BIM The Digital Plan of Work Page 30

34 The Plain Language Description 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 2 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. BIM The Digital Plan of Work Page 3

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 00 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 00 Assigning a Component to previously defined System System Ground Floor Lighting includes Component Light Fitting LF 00 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. This note is seeking information about these other approaches. BIM The Digital Plan of Work Page 32

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. 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? 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. BIM The Digital Plan of Work Page 33

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 23: The Assembly is located within a space with walls, a slab and a door Figure 24: The owning ClassRoomLayout and the owned furniture have representations Figure 22: The Assembly consists of 6 desks, 33 chairs and a whiteboard Figure 25 - The owning ClassRoomLayout has some user defined properties BIM The Digital Plan of Work Page 34

38 Technical Definitions & Specifications 2 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. Name CreatedBy CreatedOn AssemblyType SheetName ParentName ChildNames ExtSystem ExtObject ExtIdentifier Description Stair: Commercial - Ext Steel Fire escape:23759 assembly 0 Fixed Component Stair: Commercial - Ext Steel Fire escape: Stair: Commercial - Ext Steel Fire escape: IfcStair Stair: Commercial - Ext Steel Fire escape: 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. Stair: Commercial - Ext Steel Fire escape:23759 assembly 02 Stair: Commercial - Ext Steel Fire escape:23759 assembly 03 Fixed Fixed Component Component Stair: Commercial - Ext Steel Fire escape: Stair: Commercial - Ext Steel Fire escape: Railing:00 mm:23832 Railing:00 mm:23836 Table : COBie Assembly (Components) Component Assemblies can be qualified with Coordinate information. Components can be given Point locations with orientations. IfcRailing IfcRailing Railing:00 mm:23832 Railing:00 mm:23836 Both the owner and owned objects have entries in the Component table. BIM The Digital Plan of Work Page 35

39 Technical Definitions & Specifications 2 Name CreatedBy CreatedOn Category Stair:Commercial - Ext Steel Fire escape:23759 assembly 0 point point Assembly SheetName RowName CoordinateXAxis CoordinateYAxis CoordinateZAxis Stair:Commercial - Ext Steel Fire escape:23759 assembly Stair:Commercial - Ext Steel Fire escape:23759 assembly 02 point point Assembly Stair:Commercial - Ext Steel Fire escape:23759 assembly Stair:Commercial - Ext Steel Fire escape:23759 assembly 03 point point Assembly Stair:Commercial - Ext Steel Fire escape:23759 assembly 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. The owning Type, the owned Types and/or the Assembly row can have document, attributes and impacts associated BIM The Digital Plan of Work Page 36

40 Technical Definitions & Specifications 2 Name CreatedBy CreatedOn AssemblyType SheetName Basic Roof:Flat - Warm Concrete layer 0 Layer Type ParentName ChildNames Basic Roof:Flat - Warm Concrete Roofing - Felt IfcMaterialLayer Roofing - Felt : 4. ExtSystem ExtObject ExtIdentifier Description Basic Roof:Flat - Warm Concrete layer 02 Layer Type Basic Roof:Flat - Warm Concrete Insulation / Thermal Barriers - Rigid insulation IfcMaterialLayer Insulation / Thermal Barriers - Rigid insulation : 50. Basic Roof:Flat - Warm Concrete layer 03 Layer Type Basic Roof:Flat - Warm Concrete Concrete - Sand/Cement Screed IfcMaterialLayer Concrete - Sand/Cement Screed : 50. Basic Roof:Flat - Warm Concrete layer 04 Layer Type Basic Roof:Flat - Warm Concrete layer 05 Layer Type Basic Roof:Flat - Warm Concrete Concrete - Cast In Situ IfcMaterialLayer Concrete - Cast In Situ : 50. Basic Roof:Flat - Warm Concrete Plaster IfcMaterialLayer Plaster : 2.5 BIM The Digital Plan of Work Page 37

41 Technical Definitions & Specifications 2 Type Assemblies can be qualified with Coordinate information Each Assembly row can be given a Top Left and Bottom Right coordinate Spaces, Cavities and Voids need not be documented Name CreatedBy CreatedOn Category SheetName Basic Roof:Flat - Warm Concrete layer 0 box-lowerleft box-lowerleft Assembly RowName CoordinateXAxis CoordinateYAxis CoordinateZAxis ExtSystem Basic Roof:Flat - Warm Concrete layer IfcMaterialLayer ExtObject ExtIdentifier Basic Roof:Flat - Warm Concrete layer 0 box-upperright box-upperright Assembly Basic Roof:Flat - Warm Concrete layer 02 box-lowerleft box-lowerleft Assembly Basic Roof:Flat - Warm Concrete layer 02 box-upperright box-upperright Assembly Basic Roof:Flat - Warm Concrete layer 03 box-lowerleft box-lowerleft Assembly Basic Roof:Flat - Warm Concrete layer 03 box-upperright box-upperright Assembly Basic Roof:Flat - Warm Concrete layer IfcMaterialLayer Basic Roof:Flat - Warm Concrete layer IfcMaterialLayer Basic Roof:Flat - Warm Concrete layer IfcMaterialLayer Basic Roof:Flat - Warm Concrete layer IfcMaterialLayer Basic Roof:Flat - Warm Concrete layer IfcMaterialLayer Table 3: COBie Coordinate (Type Assembly) BIM The Digital Plan of Work Page 38

42 Technical Definitions & Specifications 2 IFC representations of assemblies Component assemblies are documented using the Aggregation relationship between Ifc Elements. elaggregates.htm Implementers agreements currently request that nesting is not taken beyond one level. Relative setting out is handled separately. ource/lexical/ifclocalplacement.htm 5.2 Type assemblies for constructions are documented using the Ifc Material Layer relationship between Ifc Material Layer Set and Ifc Materials, which includes layer thicknesses /lexical/ifcmateriallayer.htm Material Layer Sets contain Materials so only one level is possible. Checking For Compliance Introduction The BIM task Group has already published an outline guide to COBie-UK-202 including checklists for compliance. It is expected that subsequent submissions of COBie datasets should show continuity whilst adding more detail. Recently the published template has been developed into the COBie-UK-202 demand matrix. These publications allow the development of tools to check the quality of COBie datasets. Since the first steps of UK BIM implementation, the importance of levels of detail within BIM adoption have been recognised. The recurrent remark for the need to identify what information was to be exchanged and when, has led to the development of a UK BIM Element and Attribute Demand Matrix. The UK BIM Element and Attribute Demand Matrix (COBie-UK- 202_DemandMatrix.xls based on COBie), starts to provide standards for information necessary to include in BIM models from inception through project delivery establishing what information is exchanged at several project stages. This guidance is presented as a COBie-like document to be used for identifying and tracking BIM information, it covers Building Information Types, (as well as Facility, Floors, Systems and Spaces), when they are relevant, and to what level of development (in-line with CIC stages) throughout a building lifecycle. The Systems, Types and Spaces elements are organized and ordered by general Uniclass classification and properties listed as Attributes, marked with the CIC stage by which they are expected. BIM The Digital Plan of Work Page 39

43 Technical Definitions & Specifications 2 To prove the concept the demand matrix is being tested to show how the information listed under spatial and physical objects could be used to answer clients questions. Using a Classroom as an example, 0 Types from the Object Matrix were prioritised (FFE, Doors, Windows, Wall exterior, Wall interior, General Lighting, Audio Visual, Telecommunications and Data Network). The properties presumed to answer clients question were selected and included on the Classroom BIM model at specific project stages (released as IFC and as COBie at four specific CIC stage-gates). To demonstrate automated checking, a single application (developed by AEC3) generates three separate marked up versions of a COBie submittal that show: o Compliance with the COBie standard, checking data integrity o Continuity is judged by detecting the addition and removal of objects and attributes, along with changes. o Completeness is judged against a list of properties and attributes along with the expected stage at the end of which they should be provided. Deliverables: o Standard_Classroom_CIC_n.ifc (example classroom model at CIC stages 2,3,5,6) o Standard_Classroom_CIC_n_asCOBie.xls (example classroom COBie at CIC stages 2,3,5,6) AEC3 has developed the COBie-UK-202 tool and the underlying rule sets for the UK BIM task Group to distribute. Neither AEC3 nor the UK BIM Task Group makes any warranty on the speed or efficacy of the tools. Issues of compliance, continuity and completeness are ultimately professional and contractual judgements. The application is at alpha stage of development, and some functionality has yet to be tested. Comments, observations and suggestions may be sent either to BIM task group or to nn@aec3.com. Compliance, Continuity and Completeness Examples: o COBIe-UK-202.msi (installer for a Windows 64-bit application, including three open-source rules sets, and this handbook). o COBie-UK-202_DemandMatrix.xls (COBie-like summary of expected attributes by CIC stage-gates). Figure 26: Checking Application interface BIM The Digital Plan of Work Page 40

44 Technical Definitions & Specifications 2 The application generates three separate marked up versions of the COBie, with highlights in red, amber and green with comments on the sheets, rows and cells that are: o non-compliant. (Compliance) o additions, changes and deletions since an earlier version (Continuity) o excessive or missing data for the current stage (Completeness). All issues are classified but the appropriate remedial action may not necessarily be the one recommended, especially if the issues arose in a model or database. Issues represent the general opinion of the authors of the relevant standards and other recommendations. Issues are graded by their anticipated serious from the point of view of the client as recipient. Figure 27: Example file selection The following sections discuss the Compliance, Continuity and Completeness criteria. Quick reference Compliance Continuity Completeness Red Broken Removed Late Amber Incomplete Changed Expected Green Inadequate* Added Early Note: Judgement is still required to evaluate the accuracy of the reports and the appropriate action. *A green cell may still require examination and correction. BIM The Digital Plan of Work Page 4

45 Technical Definitions & Specifications 2 Outcomes The outcomes are available as o Three marked up COBie datasets with red, amber and green issues highlighted. o A detailed log of the same issues Uses The mark-up and log can be used to monitor o evolving supply side deliverables o planned demand side deliveries o third party COBie authoring and generation applications The Red/Amber/Green coloration may form the basis of a scoring mechanism, typically based on an estimated number of hours effort needed to resolve the issues. Additional checks The rules are captured in an open rule format (XSLT) designed to be applied to an open XML representation of the COBie (Spreadsheet XML 2003). Users can therefore review and extend the rules set. The COBie-UK-202 application can be replaced with openly available XSLT toolkits (such as Saxon, Xalan, Altova or MsXML). Interactive usage The user may make a desktop shortcut to the expected location of the program and/or this supporting documentation. C:\Program Files\AEC3\BimServices\COBie-UK-202.exe C:\Program Files\AEC3\BimServices\COBie-UK-202.pdf Command line usage To check compliance only: COBie-UK-202.exe current.xlsx >current.log dir current_compliance.xlsx dir current.log To check compliance and continuity: COBie-UK-202.exe previous.xlsx current.xlsx >current.log dir current_compliance.xlsx dir current_continuity.xlsx dir current.log To check compliance, continuity and completeness: COBie-UK-202.exe demand.xlsx previous.xlsx current.xlsx >current.log dir current_compliance.xlsx dir current_continuity.xlsx dir current_completeness.xlsx dir current.log COBie-UK-202.exe (see screen shots above) BIM The Digital Plan of Work Page 42

46 Technical Definitions & Specifications 2 Compliance Compliance is judged by reference to the COBie data schema and other requirements. Compliance requirements Compliance with the COBie standard checks data integrity. This stage does not check the continuity nor completeness. Compliance checks The following COBie structural and content checks are made: No unexpected sheets Sufficient contacts (one or more) and facility (exactly one) row. Unique rows - no duplication of objects or supplementary data) Relational integrity any reference cell (pink) refers to some other valid row Relational integrity - valid picks from pick-lists Valid dates, s, numbers Useful values in mandatory cells In addition the following UK expectations are checked: Facility.Phase shall use the format CIC n : aaaaaaa This is critical for subsequent Completeness checking see section 3. The region is set to en-uk or en-gb This confirms that UK classification is expected Each Space is assigned to at least one Zone This supports the overall business case Each Component is assigned to at least one System This supports the focus on cost, carbon and value. Origination of compliance rules The sources for these rules include: Published COBie internal rules COBie Responsibility matrix COBie-UK-202 documentation Additional UK expectations (see above). Compliance checking method All sheets are copied, and checks are applied on the Sheets, Rows and Cells. Compliance RAG All issues found are graded but appropriate the remedial action may not necessarily be obvious, especially if the issues arose from a model or database. Judgement is still required to evaluate the accuracy of the reports and the appropriate action. Compliance Red Broken Broken or duplicated entries Amber Incomplete Green Inadequate* Poor value Note: *A green cell may still require examination and correction. BIM The Digital Plan of Work Page 43

47 Technical Definitions & Specifications 2 Example Continuity requirements Continuity is expected where a series of deliverables are made to the client Continuity is based on the unique naming of COBie objects and supplementary data Continuity checks. Sheets are matched and checked for additions, changes, or deletions. 2. Rows are matched (by unique name, compound name or by row position) and checked for additions, changes, or deletions. Figure 28: Example Compliance issues marked up on the Contact sheet BimServices COBie-UK v t2:00:00 licenced to AEC3 UK Ltd. _Compliance v of COBie by AEC3 UK Ltd on T2:2:57 Table! Contact Broken : Contact ejesus@unknown.com Category n/a does not match an entry in its PickList. (unmatched pick). Inadequate : Contact ejesus@unknown.com Company n/a. (unuseful value). Inadequate : Contact ejesus@unknown.com Phone n/a. (unuseful value). Row matching by ExtIdentifier (GlobalId or GUID) is not attempted. 3. Cells are matched and checked for additions, changes, or deletions. Origination of continuity rules It includes Implied COBie process rules COBie-UK-202 documentation Continuity checking method All sheets are examined, and checks are applied on the Sheets, Rows (with those Cells that contribute to the unique identity of each Row), and finally on the content of Cells. Continuity Continuity is judged by detecting the addition and removal of objects and attributes, along with changes. BIM The Digital Plan of Work Page 44

48 Technical Definitions & Specifications 2 Continuity RAG All changes detected are graded and logged. Judgement is still required to evaluate the accuracy of the reports and any appropriate action. Continuity Red Removed Data is re-instated Amber Changed Previous value is added as a comment Green Added Data that has been added Example Continuity v of COBie relative to previous baseline by AEC3 UK Ltd on T5:3:34 Param : baseline taken as C:\COBie2\Standard_Classroom_CIC_5_asCOBie2.xml Table! Component Changed : Component Twin Switched Socket Outlet:PROJECTOR:PROJECTOR:95895 CreatedOn T5:56:4.000 to T6:00: Changed : Component Twin Switched Socket Outlet:PROJECTOR:PROJECTOR:95895 TypeName Twin Switched Socket Outlet:PROJECTOR to n/a Changed : Cell : T5:56:4.000 to T6:00: Changed : Cell : Twin Switched Socket Outlet:PROJECTOR to n/a Completeness It is not possible to automatically verify the completeness of the list of Components and Spaces. See COBie-UK-202 documentation for guidance on the expected Components and Spaces. Compliance requires that at least one System and Zone should exist for all Components and Spaces respectively and that Floors and Types should exist for all Spaces and Components respectively. Figure 29: Continuity issues found on a Component sheet. Type references have been lost. Completeness is judged against a list of properties and attributes along with the stage at the end of which they are expected. BIM The Digital Plan of Work Page 45

49 Technical Definitions & Specifications 2 Compliance requires that the Facility.Phase must be marked according to CIC stages such as CIC 2 : Design. programme. However, the Demand Matrix can be maintained and developed so as to be as generic and re-usable as possible. Demand side matrix Amongst the many possible presentations of the Demand Matrix, the most directly useful form is to use COBie itself. This has the following benefits:. COBie is naturally familiar and so no new nor informal structure is needed. Figure 30 - COBie facility sheet showing the current CIC stage (extreme right hand side) Completeness requirements Given the lists of these objects, it is possible to check that the expected object properties, Attributes and Impacts and Documents have been provided. The next level of specification and checking rests on the preparation of a matrix of COBie Objects (Facility, Floor, Space, Zones, Types, Systems and Components), their attributes and relationships and the stage gates they are expected as part of the Employers Information Requirements. What? Object and specialisation What aspect? Property or attribute When expected? On completion of Corridor spaces Net area CIC 3 : Design development Note that since COBie is expected to be specified as part of the Employers Information Requirements, the Demand Matrix may be specific to a project or 2. Existing templates and examples can be rapidly re-used. Best practice can be automatically cut-and-pasted from existing COBie models. 3. Descriptions, enumerated allowed values and complex types (lists, tables, ranges) are available. Assignment to property sets can be documented. 4. COBie authors can cut-and paste from the Matrix. 5. Checking applications can consume both the received COBie and the Matrix systematically. 6. Classification references can be included. Note that the methodology is independent of any specific choice of classification, as long as the chosen table is used in both the Demand matrix and the COBie model. 7. Both COBie Object sheets (facility, system, component, type, floor, zone, space etc) and COBie Supplementary sheets (attribute, document, impact etc) can have the demands documented. Examples of the COBie Object and Supplementary sheets with expected gate of delivery appear below. BIM The Digital Plan of Work Page 46

50 Technical Definitions & Specifications 2 Stages The matrix will document the expected delivery gate: specifically it will identify the stage at the end of which the gate occurs. This is preferable to identifying drop numbers which may be redefined by the client. The current drop names can be correlated against with the CIC stage gate names. UK CIC Scope of Work (COBie Facility.Phase) UK BIM task group footballs CIC : Brief and early design Drop CIC 2 : Concept CIC 3 : Design Development issued for tender Drop 2a CIC 4 : Tender submission Drop 2b CIC 5 : Contractors design development and planning Drop 3 CIC 6 : Handover Drop 4 Note: the description of the facility phase (after the colon) is not significant in the Completeness checking. Supply side The Demand matrix is intended to document the Demand-side expectations. It can be further amplified to document information requirements within the design and construction Supply chains. The stage at which each specific the information is first captured or documented may be earlier than the stage at which it is expected by the Client. Some data may be expected by agreed processes internal to the Supply side even if not demanded by the Client. Within a specific project, responsibility for authoring can be documented using the Created By column, inserting entries from the Contact tab. Similarly the stage gate at which objects should be supplied can be documented in the Created On column. Any such internal Supply side information is not checked by the Completeness rule-set. Note that if the Supply side does develop the matrix further, it must fit within, and not conflict with, the Demand Matrix as referenced from the EIR. For example, the Supply chain should not plan to first supply data at a stage later than when it is being demanded. Spatial and Physical Demand Matrix Both COBie models and the Demand matrix cover two distinct information aspects: about the spatial objects (Floors, Spaces and Zones) and about the physical objects (Components, Systems and Types). The variety of physical objects means that the demands will be for more extensive compared to those about the spatial objects. Demand Matrix Each demand matrix needs to specify two distinct aspects: demands on the fixed objects sheets, and the demand on the supporting attribute sheets. Object Demand Matrix The expected stage that the fixed columns on the COBie object sheets can be documented. Some Sheets will need several rows to cover all the potential object specialisations and predefined types. Where there are several specialisations, such as types of Space, the category attribute is used to create a correspondence between the Demand Matrix and the Model. BIM The Digital Plan of Work Page 47

51 Technical Definitions & Specifications 2 The stage at which the flexible rows on the COBie supplementary sheets are expected can be documented. Most attention is needed on the Attribute sheet. Figure 30: Example of a COBie Demand Matrix for Spaces In this example, Spaces should be created during the briefing stage, but the net area is not expected until after design development. The room tag may not be determined until handover. The following object sheets are included in the Completeness check: (a) Contact (b) Facility (c) System, Type, Component (d) Zone, Floor, Space Entries in the object sheets in the Demand Matrix are related to entries in the object sheets in the current COBie model by their category (classification) codes. Component entries are related through the classification of their Types. Exceptionally, the single Facility entry is directly related, without use of any category connection. Supplementary Demand Matrix The following supplementary sheets are included in the Completeness check: (a) Attribute, Document, Impact (b) Spare and Job Figure 3: Example from a COBie Demand Matrix Supplementary tab for Attributes In this example, Spaces should be given an Occupancy Number (part of the property set for Space Occupancy) during the briefing stage, but the Net Volume (part of the set of Base Quantities) is not expected till Design development is completed. Entries in the supplementary sheets in the Demand Matrix are related to entries in the supplementary sheets in the current COBie model by the category (classification) codes of their owning objects. Entries in the Supplementary sheets of Components are related through the classification of their Types. The key value on these supplementary sheets, where the expected CIC stage is documented, are: BIM The Digital Plan of Work Page 48